0

I wanted to transfer many git repos from my old Windows 7 machine (git 2.6.3.windows.1) to the new one under Ubuntu 16.04 (git 2.7.4). Since not all of them had a remote repos I decided simply copy them. This should work. However, all tracked files in all repos became unstaged. Actually there are possible some of them which were not committed before repos transferring but the majority of them were committed.

If I look at diff for the file which was committed before repo transferring with a command:

$git log -p -1 .gitignore
commit c566830cd3ffdf96556d29aee8dd1dc95d359872
Author: Pavel <mail@mail.com>
Date:   Fri May 13 18:07:25 2016 +0300

    Start

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..c2535fe
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+__pycache__
+.idea
+test

it returns the reference to the last commit where this file was actually committed. The commit in the example above is the first one in the repo.

So, for some reason git refuses to recognize committed files but link them to the last commit where they were actually committed.

Is it the incompatibility issue of different git versions or platforms or something else? And how to solve this issue and don't brake repos?

2

Are these actual changes? Seems to me like git is just complaining that the files' attributes are different, which certainly will happen between different OSes (because Windows and Linux have different file systems with different metadata).

How about creating a "bare" clone.

ON WINDOWS

Go to some folder, e.g.:

cd c:\mycode

Locally clone your repo into this folder using the bare option, this means NOTHING will be checked out, just metadata:

git clone --bare <path_of_your_repo>

Now, zip up the resulting folder (e.g. "c:\mycode\<folder>.git") and manually transfer it to Linux.

ON LINUX

On Linux, first copy over the zipped folder from Windows, and unzip it. Now, clone to some new folder, e.g.:

mkdir ~/mynewcode
cd ~/mynewcode
git clone /<where_you_copied_and_unzipped>/<folder>.git    <--- i.e. this is the folder copied/unzipped from Windows

And, you can now change origin if you want to throw away the unzipped Windows folder.

git remote set-url origin <new_origin>

OR, just remove it altogether:

git remote rm origin
| improve this answer | |
  • No, these are not actual changes, so your guess is probably correct. Thank you for the suggested solution, it seems reasonable. However, I'm not able to check it just now, but when I'll have access to the Windows machine I'll check it and report. – DrDom Jun 22 '16 at 2:58
  • Yep, it works! I have copies of repos on my Ubuntu machine, I cloned them with bare option and then cloned again from the obtained repos. So this can be done even after repos were copied on a destination Ubuntu machine. Of course I lost information about real remote repos but this is not a big deal to fix it. Thank you! – DrDom Jun 22 '16 at 4:46
  • Glad that helped. I've read and experimented with ways to "bare" an existing repo, so you don't destroy metadata like origin. Seems like it can only be done by manually deleting stuff and renaming folders, and I haven't found a simple way to do it (there must be some secret command to bare a repo). If someone knows how, then it would reduce my solution to a simple two steps; #1 bare the repo and, #2, copy the bare repo to other machine/location. – jehad Jun 22 '16 at 22:19
0

How about pushing them to github, then cloning the repo on your Ubuntu? (Would have commented, but I don't have 50 rep yet)

If you need help with that I can provide more instructions.

| improve this answer | |
  • Thanks, that is an obvious solution, but there are many repos and not all of them are public and can be uploaded on github. Simple copy usually works, but not in this case and I would like to understand why and fix it. – DrDom Jun 21 '16 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.