Re: not uptodate. Cannot merge

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 5, 2017, 15:12 UTC
Message-ID: <alpine.DEB.2.21.1.1705051708311.146734@virtualbox>
In-Reply-To: <CAAj3zPzHiwgS=2CSKP1y8zGUxHUWiq9TSeMhixeL+9ZfffY-pw@mail.gmail.com>

Hi Sylvie,

On Thu, 4 May 2017, G. Sylvie Davies wrote:

> My situation:  Git-2.10.2.windows.1 / Bitbucket-4.14.3 / Windows
> 10-10.0-amd64.   But I suspect even more recent Git will have the same
> problem.

In contrast, I suspect that recent Git for Windows versions have tons of CR/LF-related fixes... ;-)

Show 26 quoted lines

> Right after cloning I create a ".git/info/attributes" file containing
> just this one line:
> 
> * -text
> 
> 
> After the clone, here's the sequence of commands leading up to the bad
> "git reset --hard".  These are all fine (well, the "--aborts" whine a
> little, but that's expected):
> 
> git.exe branch --unset-upstream
> git.exe update-index --refresh
> git.exe rebase --abort
> git.exe cherry-pick --abort
> 
> 
> And here's the "git reset --hard" that fails:
> 
> git.exe reset --hard --quiet d6edcbf924697ab811a867421dab60d954ccad99 --
> 
> ---
> Exit=128
> error: Entry 'basic_branching/file.txt' not uptodate. Cannot merge.
> fatal: Could not reset index file to revision
> 'd6edcbf924697ab811a867421dab60d954ccad99'.
> ---

This smells very much like a problem I vaguely remember has been addressed recently: Torsten Bögershausen was working on issues where files checked out with one line ending, and then "retroactively" become dirty by changing the line ending convention (which your -text seems to do) and Git not really noticing this until the `reset --hard` call that simply cannot cope with "this kind of dirty".

In essence, I am fairly certain that v2.12.2(2) should *not* display this behavior.

If my hunch is wrong, please do fill out a full bug report at https://github.com/git-for-windows/git/issues/new, preferably with a short and sweet script to reproduce the problem elsewhere.

Thanks, Johannes