Copying Git repository from Linux to Windows.
Hello,
I wanted to copy my complete Linux GIT repo from Linux PC to Windows. I also wanted everything related to remote branches too, so need to copy and clone and fetch wouldn't work.
I don't have windows on same network, so i need to copy to memory stick and then to Windows PC.
After completing copy operation on mem stick, i found something strange.
- git branch shows correct results and is exactly same of state at Linux machine.
- git log is also fine.
- git status, shows me a lot of files are modified, which is not present in Linux.
- git reset --hard also doesn't work and fails with following error.
$ git reset --hard HEAD error: unable to create symlink arch/microblaze/boot/dts/system.dts (Operation not permitted) Checking out files: 100% (36696/36696), done. fatal: Could not reset index file to revision 'HEAD'.
Any help about this issue would be very helpful.
Signature · 1 line
viresh
Quoted 14 lines · viresh kumar
Hello,
I wanted to copy my complete Linux GIT repo from Linux PC to Windows. I also wanted everything related to remote branches too, so need to copy and clone and fetch wouldn't work.
I don't have windows on same network, so i need to copy to memory stick and then to Windows PC.
After completing copy operation on mem stick, i found something strange.
- git branch shows correct results and is exactly same of state at Linux machine.
- git log is also fine.
- git status, shows me a lot of files are modified, which is not present in Linux.
- git reset --hard also doesn't work and fails with following error.
Quoted 8 lines
$ git reset --hard HEAD error: unable to create symlink arch/microblaze/boot/dts/system.dts (Operation not permitted) Checking out files: 100% (36696/36696), done. fatal: Could not reset index file to revision 'HEAD'.Any help about this issue would be very helpful.
The Linux kernel repository isn't very good to work with on Windows machines, or anywhere where the filesystem is either case-insensitive or case-agnostic.
One reason is that it contains symlink. The other is that there are files sharing the same name and only differ in case.
I suppose the main thought behind it is that Linux kernel hackers almost exclusively use Linux (which has sane filesystems) to do their work, so it hasn't been rectified in the 5 or so years it has been a known (non-)problem.
Signature · 7 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace.
Quoted 9 lines · viresh kumar
I wanted to copy my complete Linux GIT repo from Linux PC to Windows. I also wanted everything related to remote branches too, so need to copy and clone and fetch wouldn't work.
I don't have windows on same network, so i need to copy to memory stick and then to Windows PC.
After completing copy operation on mem stick, i found something strange.
- git branch shows correct results and is exactly same of state at Linux machine.
- git log is also fine.
- git status, shows me a lot of files are modified, which is not present in Linux.
That is probably because stat information is stale... or stat information doesn't work. Does second "git status" still show files as modified?
Quoted 7 lines
- git reset --hard also doesn't work and fails with following error.
$ git reset --hard HEAD error: unable to create symlink arch/microblaze/boot/dts/system.dts (Operation not permitted) Checking out files: 100% (36696/36696), done. fatal: Could not reset index file to revision 'HEAD'.
Try setting core.symlinks to false, or just try
$ git -c core.symlinks=false reset --hard HEAD
Notice that your repository includes symlinks.
BTW. what filesystem do you use?
Signature · 3 lines
Jakub Narebski Poland ShadeHawk on #git
Quoted 10 lines · Jakub Narebski
Quoted 4 lines · viresh kumar
After completing copy operation on mem stick, i found something strange.
- git branch shows correct results and is exactly same of state at Linux machine.
- git log is also fine.
- git status, shows me a lot of files are modified, which is not present in Linux.That is probably because stat information is stale... or stat information doesn't work. Does second "git status" still show files as modified?
Yes. The files status is same.
Quoted 7 lines
Quoted 6 lines
- git reset --hard also doesn't work and fails with following error.
$ git reset --hard HEAD error: unable to create symlink arch/microblaze/boot/dts/system.dts (Operation not permitted) Checking out files: 100% (36696/36696), done. fatal: Could not reset index file to revision 'HEAD'.
Quoted 9 lines
Try setting
core.symlinksto false, or just try$ git -c core.symlinks=false reset --hard HEADNotice that your repository includes symlinks.
BTW. what filesystem do you use?
It was FAT on memory stick as FAT is also there in Windows PC.
More observation: All files marked modified had only changes in file permissions. i.e. 755 instead of 644. chmod doesn't work with FAT so can't change there permissions now.
Problem is not only for symlinks but standard c files too.
Signature · 1 line
viresh
Quoted 24 lines · viresh kumar
Quoted 10 lines · Jakub Narebski
Quoted 4 lines · viresh kumar
After completing copy operation on mem stick, i found something strange.
- git branch shows correct results and is exactly same of state at Linux machine.
- git log is also fine.
- git status, shows me a lot of files are modified, which is not present in Linux.That is probably because stat information is stale... or stat information doesn't work. Does second "git status" still show files as modified?
Yes. The files status is same.
Quoted 10 lines
Quoted 6 lines
- git reset --hard also doesn't work and fails with following error.
$ git reset --hard HEAD error: unable to create symlink arch/microblaze/boot/dts/system.dts (Operation not permitted) Checking out files: 100% (36696/36696), done. fatal: Could not reset index file to revision 'HEAD'.Try setting
core.symlinksto false, or just try$ git -c core.symlinks=false reset --hard HEAD
[...]
Quoted 7 lines
Quoted 2 lines
BTW. what filesystem do you use?
It was FAT on memory stick as FAT is also there in Windows PC.
More observation: All files marked modified had only changes in file permissions. i.e. 755 instead of 644. chmod doesn't work with FAT so can't change there permissions now.
Ah. This is caused by the fact that FAT doesn't store executable permission.
Quoted 1 line
Problem is not only for symlinks but standard c files too.
So beside setting core.symlinks to false, you would have also set core.filemode to false (and perhaps also core.ignorecase to true).
You might also want to set core.ignoreStat to true to try to increase performace.
P.S. git-bundle ddidn't work?
Signature · 2 lines
Jakub Narebski Poland
Quoted 10 lines · viresh kumar
Quoted 2 lines · Jakub Narebski
BTW. what filesystem do you use?
It was FAT on memory stick as FAT is also there in Windows PC.
More observation: All files marked modified had only changes in file permissions. i.e. 755 instead of 644. chmod doesn't work with FAT so can't change there permissions now.Problem is not only for symlinks but standard c files too.
Sounds like you should try "git config core.filemode false":
"core.fileMode:
If false, the executable bit differences between the index and
the working copy are ignored; useful on broken filesystems like FAT"
(from from http://kernel.org/pub/software/scm/git/docs/git-config.html)
Quoted 11 lines · Erik Faye-Lund
Quoted 1 line · viresh kumar
On 06/15/2011 04:10 PM, Jakub Narebski wrote:
Sounds like you should try "git config core.filemode false":
"core.fileMode:
If false, the executable bit differences between the index and
the working copy are ignored; useful on broken filesystems like FAT"(from from http://kernel.org/pub/software/scm/git/docs/git-config.html)
.
Quoted 6 lines · Jakub Narebski
Quoted 2 lines · viresh kumar
Quoted 1 line · Jakub Narebski
viresh kumar <[email protected]> writes:
Ah. This is caused by the fact that FAT doesn't store executable permission.
Quoted 7 lines
So beside setting
core.symlinksto false, you would have also setcore.filemodeto false (and perhaps alsocore.ignorecaseto true).You might also want to set
core.ignoreStatto true to try to increase performace.
P.S. git-bundle ddidn't work?
didn't tried that. :(
Quoted 1 line
Guys, thanks for your inputs. core.filemode was new to me.
I tried to resolved issue in some other way.
I have tarred kernel before copying to memory stick. And after untarring kernel on windows, file permission are not changed for all files with permission 644 originally.
There are some files in kernel whose permissions are 755 and they are converted to 644. And are shown in git status as _modified_.
I got rid of them with core.filemode as false, but there is one more issue, as pointed out by Andreas. There are few files in kernel with same file name but in different _cases_ (one in caps and another in small.) and so i am getting issues with these now.
And don't have any idea how to get rid of that? And why does kernel have such file names at all?
Signature · 1 line
viresh
Quoted 5 lines · viresh kumar
Quoted 3 lines · Jakub Narebski
Ah. This is caused by the fact that FAT doesn't store executable permission.
Quoted 8 lines
Quoted 2 lines
So beside setting
core.symlinksto false, you would have also setcore.filemodeto false (and perhaps alsocore.ignorecaseto true).[...], but there is one more issue, as pointed out by
Andreas. There are few files in kernel with same file name but in different _cases_ (one in caps and another in small.) and so i am getting issues with these now.And don't have any idea how to get rid of that?
core.ignorecase::
If true, this option enables various workarounds to enable git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds "makefile" when git expects "Makefile", git will assume it is really the same file, and continue to remember it as "Makefile".
The default is false
But that wouldn't unfortunately help when there are two files which filename differs only in case.
You would have to do tricks with git update-index and its --assume-unchanged bit (though perhaps core.ignorecase would be enough) and --cacheinfo <mode> <object> <path> together with git hash-object -w...
Or perhaps delete file which you have in working area, checkout one file, add it, checkout other file, add it, use 'git commit' and not 'git commit -a'.
But that are only possible solutions; I have sane filesystem.
Can't you work on NTFS, and use USB stick only for transport of either tarred repository, or bundle?
Quoted 1 line
And why does kernel have such file names at all?
That I don't know.
Signature · 2 lines
Jakub Narebski Poland
Quoted 19 lines · Jakub Narebski
core.ignorecase::
If true, this option enables various workarounds to enable git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds "makefile" when git expects "Makefile", git will assume it is really the same file, and continue to remember it as "Makefile".The default is false
But that wouldn't unfortunately help when there are two files which filename differs only in case.
You would have to do tricks with
git update-indexand its --assume-unchanged bit (though perhapscore.ignorecasewould be enough) and--cacheinfo <mode> <object> <path>together withgit hash-object -w...
Quoted 8 lines
Or perhaps delete file which you have in working area, checkout one file, add it, checkout other file, add it, use 'git commit' and not 'git commit -a'.
But that are only possible solutions; I have sane filesystem.
Can't you work on NTFS, and use USB stick only for transport of either tarred repository, or bundle?
FWIW - NTFS likely does not help here because even though NTFS supports unique-cased filenames, Windows and Win32-apps do not.
http://support.microsoft.com/kb/100625
For example,
cmd.exe:
C:\> touch makefile
C:\> copy makefile Makefile
The file cannot be copied onto itself.
0 file(s) copied.
cygwin/bash:
$ touch makefile $ cp makefile Makefile cp: `makefile' and `Makefile' are the same file
Linux (on NTFS volume):
mnt/NTFS: touch makefile mnt/NTFS: cp makefile Makefile mnt/NTFS: ls *akefile
makefile Makefile
Mac's "HFS Plus" filesystem supports unique-on-case, but it is not safe to enable it on a boot disk.
http://support.apple.com/kb/TA21400?viewlocale=en_US
Phil
Quoted 6 lines · viresh kumar
I got rid of them with core.filemode as false, but there is one more issue, as pointed out by Andreas. There are few files in kernel with same file name but in different _cases_ (one in caps and another in small.) and so i am getting issues with these now.
And don't have any idea how to get rid of that?
You can't. git dubs such filesystems as "retarded" and simply can't work around it. Imo, that's the only sensible thing to do.
Quoted 2 lines
And why does kernel have such file names at all?
Because linux kernel developers are expected to work with linux development work using linux and nowhere near enough find it an actual problem for anyone to care about fixing it. Note that all build-scripts and configuration stuff will have to be fixed as well. Complaining about it on lkml will probably have very little effect unless you're a very valuable contributor and/or lots of other people chime in to agree with you.
If I may ask; Why do you need to be able to work with a linux kernel repository on windows?
Signature · 7 lines
Andreas Ericsson [email protected] OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace.
Quoted 2 lines · Andreas Ericsson
If I may ask; Why do you need to be able to work with a linux kernel repository on windows?
I can't simply install Linux on my office laptop (company policies, support, etc) :(
And i wanted just linux source on windows, i will not be creating any patches from windows. Just needed code for reference.
Signature · 1 line
viresh
Quoted 9 lines · viresh kumar
Quoted 2 lines · Andreas Ericsson
If I may ask; Why do you need to be able to work with a linux kernel repository on windows?
I can't simply install Linux on my office laptop (company policies, support, etc) :(
And i wanted just linux source on windows, i will not be creating any patches from windows. Just needed code for reference.
Browsing code via gitweb (in a web browser) is not enough?
Signature · 2 lines
Jakub Narebski Poland
Quoted 10 lines · Jakub Narebski
Quoted 8 lines · viresh kumar
Quoted 8 lines · Andreas Ericsson
Quoted 2 lines
Quoted 2 lines
If I may ask; Why do you need to be able to work with a linux kernel repository on windows?
I can't simply install Linux on my office laptop (company policies, support, etc) :(
And i wanted just linux source on windows, i will not be creating any patches from windows. Just needed code for reference.
Browsing code via gitweb (in a web browser) is not enough?
It can be. But my branches wouldn't have been there. They are local. Also, i have fetched many other remote repositories, which i need.
Signature · 1 line
viresh
Am 6/16/2011 5:33, schrieb viresh kumar:
Quoted 2 lines
And i wanted just linux source on windows, i will not be creating any patches from windows. Just needed code for reference.
If you only want to peek into the files, you don't need the files checked out. Just have them in a bare repository and use, e.g.,
git show master:mm/vmalloc.c
You can also use a sparse checkout to omit the questionable files from the checkout. See man git-read-tree.
-- Hannes
Quoted 10 lines · Johannes Sixt
Am 6/16/2011 5:33, schrieb viresh kumar:
Quoted 2 lines
Quoted 2 lines
And i wanted just linux source on windows, i will not be creating any patches from windows. Just needed code for reference.
If you only want to peek into the files, you don't need the files checked out. Just have them in a bare repository and use, e.g.,
git show master:mm/vmalloc.c
You can also use a sparse checkout to omit the questionable files from the checkout. See man git-read-tree.
Thanks. I am doing it this way only.
Signature · 1 line
viresh
Quoted 1 line
I can't simply install Linux on my office laptop (company policies, support, etc) :(
Why not use something like VirtualBox?
Philippe
Quoted 4 lines · Philippe Vaucher
Quoted 1 line
I can't simply install Linux on my office laptop (company policies, support, etc) :(
Why not use something like VirtualBox?
Ya. I can, but for now i really don't have to. Just wanted code for reference on windows and i got it at last. Just commited all files still showed in git status.
Signature · 1 line
viresh