not uptodate. Cannot merge

not uptodate. Cannot merge

[G. Sylvie Davies]

Hi,

My little bitbucket "cherry-pick" button is failing on Windows from a
"git reset --hard" blowing up.

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.

Now, I'm pretty far from Kansas here as you'll see from my "git clone"
invocation:

git.exe clone -c core.checkStat=minimal -c core.fileMode=false -c
core.ignoreStat=true -c core.trustctime=false -c
core.logAllRefUpdates=false --shared
C:\Users\gsylvie\dev\bb\target\bitbucket\home\shared\data\repositories\1
C:\Users\gsylvie\dev\bb\target\bitbucket\home\caches\bbClones\1


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'.
---

For now I've come up with an astonishing workaround:   I just run "git
status" afterwards, and then everything is fine!

I'm going to limp along with this remedy, but I thought I'd share it
here in case anyone has any ideas, or in case it really is a bug.


- Sylvie


p.s.  Thanks for mentioning "git-reverse.sh" in git rev news!

Re: not uptodate. Cannot merge

[Johannes Schindelin]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

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

Re: not uptodate. Cannot merge

[Torsten Bögershausen]

On 2017-05-04 23:40, G. Sylvie Davies wrote:
> Hi,
> 
> My little bitbucket "cherry-pick" button is failing on Windows from a
> "git reset --hard" blowing up.
> 
> 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.
> 
> Now, I'm pretty far from Kansas here as you'll see from my "git clone"
> invocation:
> 
> git.exe clone -c core.checkStat=minimal -c core.fileMode=false -c
> core.ignoreStat=true -c core.trustctime=false -c
> core.logAllRefUpdates=false --shared
> C:\Users\gsylvie\dev\bb\target\bitbucket\home\shared\data\repositories\1
> C:\Users\gsylvie\dev\bb\target\bitbucket\home\caches\bbClones\1
> 
> 
> Right after cloning I create a ".git/info/attributes" file containing
> just this one line:
> 
> * -text
This -may- be part of the problem.
In general, it is possible to add attributes on your local copy like
this, but it is not recommendet, at least not from me.
In general, the project should have a .gitattributes file, which
belongs to the project and which travels together with push and pull.
And of course, files should have been "normalized" and have LF in the repo.

In your case:
What does
git config core.autocrlf
say?

[]