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.
> 

> 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'.

> viresh kumar <viresh.kumar@st.com> writes:
>> 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?
> 

>> - 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?
> 

> On 06/15/2011 04:10 PM, Jakub Narebski wrote:
>> 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.

> On Wed, Jun 15, 2011 at 1:04 PM, viresh kumar <viresh.kumar@st.com> wrote:
>> 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)
> .
> 

> On Wed, 15 June 2011, viresh kumar wrote:
>> On 06/15/2011 04:10 PM, Jakub Narebski wrote:
>>> viresh kumar <viresh.kumar@st.com> writes:
> Ah. This is caused by the fact that FAT doesn't store executable
> permission.
> 
> 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?

> 
> 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?

> Am 6/16/2011 5:33, schrieb viresh kumar:
>> > 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.

> > 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.

> viresh kumar wrote:
>> > On 06/15/2011 06:11 PM, Andreas Ericsson wrote:
>>> > > 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?

> > Ah. This is caused by the fact that FAT doesn't store executable
> > permission.
> > 
> > So beside setting `core.symlinks` to false, you would have also set
> > `core.filemode` to false (and perhaps also `core.ignorecase` to 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?

>>> 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.
> 
>>> - 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

>> 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.