Repository navigation
Support ignoring chmod changes on filesystems that do not support chmod (e.g. FAT) #378
Description
Activity
The configuration option would need to be added to the config parsing:
Line 35 in 7cd0215
Index is read in
plumbing/format/index/decoder.go, but I don't think we should change the way index is decoded for this.Maybe we could fix this by modifying
Worktree.Addhere, so that based on Config we can add some conditional behavior to ignore executable bit on file mode:Line 268 in ced875a
Sorry if this is not right place to report this.
But maybe this problem is related to this issue.
so I want this feature very much!Problem
I just want to do
git pull.
but after I manually rungit reset --hard HEAD~in command-line,
Worktree.Pull()returns "worktree contains unstagged changes" error.My environment is Windows Subsystem Linux (WSL).
But this is maybe common problem on Windows.Here is steps to reproduce:
cd {repo}{repo}is under/mnt/c/...- In WSL,
/mnt/cis C drive - If I run
git diff HEADin that repository, I get the following result:
$ git diff HEAD diff --git a/README.md b/README.md old mode 100644 new mode 1007552.
git reset --hard HEAD~
3. Compile this code and run./git-pull {repo}(git-pullis compiled command of that code)Hey, I was trying to work on this and managed to get it work for as far as staged files are concerned. However, when it comes to unstaged files, the Merkletrie package directly gets the file mode and compares it with the one in the index (this is not a problem with a staged file because we can change its git mode when it is added to the index).
I'm not super-knowledgeable on the codebase, so I would like to ask how do you think it's best to approach this? Passing down the config file to merkletrie doesn't sound like a good idea.
EDIT: I can also submit a WIP PR if you want.
i should also add that despite what the title says, it doesn't just apply to FAT volumes, it doesn't work on NTFS either, which means pretty much everywhere.
fwiw, windows Git clones repos withfilemode = falseby default. go-git should do the same (once it's implemented, of course).Reacted by Santiago M. Mola- added a commit that references this issue
on Sep 27, 2018 Any update on this? really need this for windows.
Reacted by simonransom-dan and Aleksei Igrychev
There is a common Windows issue with Unix executables in it: cloning those in Windows leads to differences between the filesystem and the git index because Windows reports 10644 for Unix 10755 files. The standard git client permits ignoring such differences transparently via the following config option:
git config core.fileMode false. A similar option is required forgo-gitotherwise it is very difficult to work with repositories containing Unix executables.More info on the behaviour of the standard git client can be found here: http://stackoverflow.com/questions/1580596
A particular example of what happens on the
go-gitclient is then found in the following earlier issue (which I will close in favour of this one for clarity): #373Up to now I failed to find where the index tree is read from the cloned file. If you give me a couple of hints where to search I would be happy to work on a patch.