2

I have a local branch in a local Git repository that I synchronize with a remote copy. That local branch has no corresponding remote branch at this point in time.

I need to rebase that local branch regularly to the newest version of the master branch of the repository which I do using the following sequence of Git commands:

git checkout master
git pull
git checkout my_local_branch
git rebase master

Whenever I do this, Git emits the following error message when the rebase operation reaches commits that contain a certain file named whatever.txt:

error: Your local changes to the following files would be overwritten by merge:
        Repo/src/whatever.txt
Please commit your changes or stash them before you merge.
Aborting

When I check using git status to see what is going on I don't see any local changes to that file at all. Because of this, I simply continue the rebase operation using git rebase --continue.

This works, i.e. the rebase operation continues but it stops again at the next commit that contains changes to whatever.txt. In that case I just execute git rebase --continue again.

The end result of the rebase is exactly as I expect it to be after executing the mentioned steps. But it puzzles me why Git stops and complains about changes to whatever.txt. For me, the error message doesn't make sense because I have no conflicting local changes. I'm just rebasing the existing commits on top of the latest master branch commit.

Some sanity checks done on whatever.txt showed the following results:

  • It is a UTF-8 (with BOM) encoded file that contains text. I cannot find any NUL characters when opening it in a HEX editor so Git should have no reason to see it as a binary file.
  • The .gitattributes file explicitly sets * text=auto and *.txt text

Does anyone have an idea why Git would stop during rebasing as described above?

ackh
  • 1,648
  • 2
  • 18
  • 36
  • 1
    That is a strange error to get during a rebase. Any chance you're on an old version of Git? (I feel like this is/was a bug and maybe it has been fixed in later versions.) Also, [this question](https://stackoverflow.com/q/5074136/184546) may offer some possible solutions. – TTT Jul 13 '22 at 16:42
  • Irrelevant side note, you can replace your first 4 commands with: `git fetch` and then `git rebase origin/master my_local_branch` . (And if you already have `my_local_branch` checked out you can leave that last branch name off.) – TTT Jul 13 '22 at 16:44
  • 1
    @TTT Thanks for your comments. `git --version` returns me `git version 2.36.0.windows.1` so it is almost the newest version. Thanks for the link, I'll try the answer tomorrow. Also, thanks for the `git fetch` hint. Less typing is appreciated. – ackh Jul 13 '22 at 16:53
  • 1
    Here's [another answer](https://stackoverflow.com/a/54027994/184546) that could also explain what's going on. – TTT Jul 13 '22 at 21:25
  • 2
    I'd bet on a case-folding issue here. – torek Jul 14 '22 at 04:06
  • @LeGEC Thanks for your input. I ran the command that you mentioned but it only returns me a single entry. – ackh Jul 26 '22 at 09:02
  • @LeGEC The output that I get from running that command lists the file `repo/src/whatever.txt` 10 times. Each entry contains the exact same path `repo/src/whatever.txt` with a unique SHA-1 hash associated with it. – ackh Jul 26 '22 at 11:50
  • Correct, the output of the above command returns 10 entries that are all lowercase. They are identical, i.e. all paths consist of the exact same sequence of ASCII characters and that particular path is also what I get from Windows Explorer. – ackh Jul 26 '22 at 12:59
  • You established that, unlike what I suggested, there is no case sensitivity issue in the path that leads to this file -- all revisions involved with the rebase always mention `repo/src/whatever.txt`, all lowercase, and no case sensitive variant of that path. On top of that: the sha-1 for that specific file is always the same, which indicates that the file doesn't change between commits. I'll remove my previous comments as they make for quite a long sequence of entries. – LeGEC Oct 31 '22 at 05:53
  • @ackh: do you still experience the same issue ? could it be that this specific file is targetted by some external automatic job ? (e.g: a linter that would react to file changes on disk, ...) – LeGEC Oct 31 '22 at 05:55
  • @LeGEC Thanks for coming back to this. From what I've seen in the meantime, there is indeed a job that modifies that file. But as far as i can tell, it should only run when a build is triggered and should not have an impact while a rebase is done. But it might still be connected in a way I don't see yet. I'll post an update if I figure out more about this. – ackh Nov 03 '22 at 09:03
  • do you have some "filewatch + rebuild" mechanism active on your PC ? (e.g: `npm build --watch`, `tsc --watch` ...) – LeGEC Nov 03 '22 at 09:06
  • I'm not aware of any running file watchers. The file is referenced by a project in a Visual Studio solution. When a build is triggered, the project file writes text into that file. But from what I observe it is only happening when a build in Visual Studio is triggered. – ackh Nov 03 '22 at 10:11

0 Answers0