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