Rebase occasionally fails - "The following untracked working tree files would be overwritten"

[vit...@gmail.com]

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. Aborting the rebase and rerunning it usually solves the issue (thought it might happen again randomly on one of the next commits)

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?

P.S This a repost of this unanswered SO question: http://stackoverflow.com/questions/21923865/git-rebase-on-windows-sometimes-fails-with-inexplicable-your-untracked-working

[Thomas Braun]

Am 28.05.2014 11:29, schrieb vit...@gmail.com:
> 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. Aborting the rebase and rerunning it usually solves the issue
> (thought it might happen again randomly on one of the next commits)
>
> I've seen a number of reports of this problem, such as this question

> <http://stackoverflow.com/questions/5074136/git-rebase-fails-your-local-changes-to-the-following-files-would-be-overwritte>,

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

What git version are you using?

If you have a way to reliable reproduce investigating will be much
easier. I'm thinking about a script which tries to pull rebase some
commits and after some hours will hopefully fail.

[Vitaly Belman]

I am using "git version 1.8.1.msysgit.1"

I'll install the latest one and see if that helps.

--
- Vitaly