4

This is something that occasionally affects some of our developers when they do a pull with rebase. For example, after making 5 commits locally to master and they run a:

git pull --rebase origin master

to make their history linear before pushing. Most of the time this works fine, but every now and then, during the "Reapplying your commits" stage, around a couple of commits in, the rebase will halt with the error:

The following untracked working tree files would be overwritten by merge

and list the files that were modified by the commit(s) that were already applied.

I've seen a number of reports of this problem, such as this question, but they are all talking about OSX and we are on Windows. Nevertheless we tried setting:

git config --global core.trustctime false

but that hasn't helped. We've made sure anti virus isn't monitoring the source controlled directories and there are no backup programs running... nothing should be touching these files during a rebase operation.

Has anyone else encountered this problem and found a cause?

Community
  • 1
  • 1
Falconne
  • 582
  • 5
  • 12
  • This is really annoying and makes rebase not as useful as it should be. – VitalyB May 28 '14 at 09:25
  • When you check those files, are there any differences / diff markings etc. IIRC you should be able to use the :1: :2: :3: file stage naming to do a diff. That is, is the 'change' just some fast status error, or are there real code differences? – Philip Oakley May 28 '14 at 09:41

1 Answers1

1

Can you make sure if there are no untracked files. If present you need to git checkout them first before doing a git rebase.

A better practise would be by doing the below steps.

Assuming you have a new git cloned repository

Create and checkout to a new local branch of your own.

git checkout -b <MyLocalBranch>

Do your change as necessary. Then.

git add .
git commit -m <message>
git review/push

Once you have pushed in your changes, go back to your master and do a git pull

git checkout master
git pull

Come back to your local branch and rebase it.

git checkout <MyLocalBranach>
git rebase -i master

Now you are good with your local branch and ready to make changes on your local branch. Also, by doing this you can have multiple local branches without creating conflicts to your master.

Chetan
  • 1,217
  • 2
  • 13
  • 27
  • This will happen even with a freshly cloned repo with no untracked files. It's not a problem of not understanding rebasing... it appears to be a known issue when background processes access files git is using, especially under OS X where the backup process is constantly monitoring files, and sometimes under Windows where programs use exclusive file locks. It appears to be fixed in new versions of git for Windows. – Falconne Feb 23 '15 at 19:55