1

I'm attempting to fast forward my branch by four commits made by someone else. However, Git keeps giving me this error:

error: Your local changes to the following files would be overwritten by merge:
    path/to/file/A
    path/to/file/B
    etc.
Please commit your changes or stash them before you merge.
Aborting

As per How do I ignore an error on 'git pull' about my local changes would be overwritten by merge? I tried git stash push --include-untracked followed by git stash drop, but that just resulted in the same error.

Following the directions in the answer to Git showing identical files as changed, I tried rm .git/index; git reset and this did shorten the list of files that Git showed as changed, but there were still some there. git reset --hard restored the list of "changed" files to its original size.

I've also tried removing .gitattributes (which has a text=auto line in it) but the files are still shown as changed. Their line endings are all LF anyway, so I doubt a line ending setting would affect these.

In a moment of desperation, I tried git rm -r -f ., which deleted everything but the .git directory, but upon trying to pull I still get the error about these files having changes that will be overwritten, even when the files are deleted. Of course when I do git reset; git status I have all of the files restored and the same set of files is shown as being changed.

I could just delete the whole repository and re-clone it, but I'd like to figure out what's going on. What is causing this behavior?

MK32
  • 63
  • 5
  • 1
    That sounds like an EOL format change. What does `gut diff` show? – eftshift0 Mar 11 '20 at 21:44
  • Did you solve the problem by re-cloning? – ElpieKay Mar 12 '20 at 01:38
  • @eftshift0 well, *gut* diff shows `bash: gut: command not found`, but *git* diff shows every line as deleted and then added back. Some blank lines in the "added" sections show red bars where whitespace seems to have been added, but Meld insists there are no differences. – MK32 Mar 12 '20 at 15:54
  • Yep, my bad on `gut`. 5 minutes had already gone by when I noticed so could not edit it. And if that's the case, it's an EOL format change, for sure. – eftshift0 Mar 12 '20 at 16:02
  • @ElpieKay I tried cloning to another directory and pulling the branch at the latest commit, which worked fine. I've still got the original copy of the repository to troubleshoot and post here for others if anyone has more suggestions. – MK32 Mar 12 '20 at 16:39

2 Answers2

1

Alright, so after a third user working on the same branch ran into the same problem, I did some more digging and found the solution.

Our repository uses a filter to change leading sets of 4 spaces to tabs. To apply the filter to each user's config, I wrote a Bash script that everyone is supposed to run before beginning work in the repository. This particular user hadn't run the script, so he didn't have the filter in place.

When I reset my local version of the repository, Git applied the filter to the files, which resulted in leading spaces being converted to tabs and Git registering a change in the file. Removing the filter temporarily allowed me to fast forward to the latest version of the branch.

I still don't know why Meld (accessed with git difftool) showed no diffs, but when I manually downloaded the repository from the server and checked those files against the changed files, Meld showed the whitespace changes.

MK32
  • 63
  • 5
0

Their line endings are all LF anyway, so I doubt a line ending setting would affect these.

Still, to be sure, check the output of git config core.autocrlf.
Set it to false: git config --global core.autocrlf false.

Then: git add --renormalize -- :/. (since Git 2.16)

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • That didn't work. The output of `git config core.autocrlf` was blank (I believe that means it wasn't set) and attempting to pull after `git config --global core.autocrlf false` and `git add --renormalize -- :/.` still gives the `error: Your local changes to the following files would be overwritten by merge` message. – MK32 Mar 12 '20 at 15:57
  • My tip on this: `core.autocrlf` is the old implementation of dealing with EOL formatting. You should _not_ use it and use the new implementation based on `.gitattributes` instead (even to tell git to _not_ mess with EOLs of files). https://www.reddit.com/r/git/comments/cqgtgw/is_there_any_way_to_100_enforce_certain_line/ – eftshift0 Mar 12 '20 at 16:04
  • @eftshift0 Yes, which is why I explicitly set it to false. Always. – VonC Mar 12 '20 at 16:06
  • @MK32 Even after a `git reset --hard`? – VonC Mar 12 '20 at 16:07
  • @VonC Yep, even after a `git reset --hard` – MK32 Mar 12 '20 at 16:12
  • @MK32 Reading https://stackoverflow.com/questions/35450049/what-does-would-be-overwritten-by-merge-mean, can you try a git stash first, the the add renormalize? – VonC Mar 12 '20 at 16:15
  • @VonC still didn't work. I noticed after `git stash` that `git status` still reported several modified files. – MK32 Mar 12 '20 at 16:21
  • If it helps, the user who made the changes has `core.autocrlf=true` in his config. – MK32 Mar 12 '20 at 16:29
  • @MK32 That user should set it to false (https://stackoverflow.com/a/20168775/6309) – VonC Mar 12 '20 at 16:42