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... ;-)

> 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