Possibly-spurious 'not uptodate. Cannot merge'

Possibly-spurious 'not uptodate. Cannot merge'

[Nix]

Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get
this:

loki 504 /usr/packages/linux/linux% git pull
remote: Counting objects: 638, done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 517 (delta 430), reused 516 (delta 430)
Receiving objects: 100% (517/517), 74.91 KiB, done.
Resolving deltas: 100% (430/430), completed with 120 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y
   078bb16..5defaf8  master     -> 2.6.27-stable/master
 * [new tag]         v2.6.27.9  -> v2.6.27.9
error: Entry 'Makefile' not uptodate. Cannot merge.
fatal: merging of trees 34f70ec1fadcaad7de6979491e2dea9da735e6f9 and ded3f44559ce050e0ef014ebce093c5d9295ede8 failed
Merge with strategy recursive failed.

In this situation, 'git diff' reports no changes at all, but 'git reset
--hard' gets the tree back into a state where merging succeeds, as does
'git update-index --refresh'.

I suspect the 'problem' is that I've hardlinked a bunch of build trees
to this tree in the interim via 'cp -al', then applied patches to each
of those trees with quilt, then deleted all those trees prior to the git
pull. This doesn't change the original files at all, but *does* update
their link count: is git getting annoyed by the corresponding change in
ctime? (If so, why did it start happening only fairly recently?)

Re: Possibly-spurious 'not uptodate. Cannot merge'

[Junio C Hamano]

Nix <nix@esperi.org.uk> writes:

> Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get
> this:
> ...
> I suspect the 'problem' is that I've hardlinked a bunch of build trees
> to this tree in the interim via 'cp -al', then applied patches to each
> of those trees with quilt, then deleted all those trees prior to the git
> pull. This doesn't change the original files at all, but *does* update
> their link count: is git getting annoyed by the corresponding change in
> ctime? (If so, why did it start happening only fairly recently?)

In git timescale 1.5.4 is not recent at all ;-)

Ancient git, whose "git merge" was a scripted command, refreshed the index
before starting, but it lost that when the command was rewritten in C soon
after v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed
it until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09).  In other
words, the tip of 'master' (and upcoming 1.6.1) already has the fix.

The fix should have been cherry-picked to 'maint' to be part of 1.6.0.X
series, but it apparently was forgotten.  Fault of mine and Shawn ;-)

Re: Possibly-spurious 'not uptodate. Cannot merge'

[Nix]

On 14 Dec 2008, Junio C. Hamano said:
> Ancient git, whose "git merge" was a scripted command, refreshed the index
> before starting, but it lost that when the command was rewritten in C soon
> after v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed
> it until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09).  In other
> words, the tip of 'master' (and upcoming 1.6.1) already has the fix.

Excellent! I do love this precognitive bugfixing thing.

(It's not as if the update-index workaround is terribly onerous, but
it's annoying and not something a git newbie might think of.)

Re: Possibly-spurious 'not uptodate. Cannot merge'

[Sitaram Chamarty]

On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
> In this situation, 'git diff' reports no changes at all, but 'git reset
> --hard' gets the tree back into a state where merging succeeds, as does
> 'git update-index --refresh'.

Wasn't there some situation in which merely running 'git
status' would have a similar effect?  I seem to recall
reading that somewhere but now I can't find any mention of
it in 'git help status'.

Re: Possibly-spurious 'not uptodate. Cannot merge'

[Junio C Hamano]

Sitaram Chamarty <sitaramc@gmail.com> writes:

> On 2008-12-14, Nix <nix@esperi.org.uk> wrote:
>> In this situation, 'git diff' reports no changes at all, but 'git reset
>> --hard' gets the tree back into a state where merging succeeds, as does
>> 'git update-index --refresh'.
>
> Wasn't there some situation in which merely running 'git
> status' would have a similar effect?  I seem to recall
> reading that somewhere but now I can't find any mention of
> it in 'git help status'.

It would, but this is a pure bug in the re-implementation of git-merge
that was introduced soon after v1.5.6.  The users shouldn't be required to
run refresh to work this around.