threads / discuss / 16727

Possibly-spurious 'not uptodate. Cannot merge'

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

## tl;dr

5 messages between Dec 14, 2008 and Dec 15, 2008.

replies: 4people: 3as markdown or json

Nix· Dec 14, 2008, 16:47 UTC · lore

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?)

Junio C Hamano· Dec 14, 2008, 19:33 UTC · re: Nix · lore

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

Nix <nix@esperi.org.uk> writes:
Show 9 quoted lines
> 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 ;-)

Nix· Dec 14, 2008, 23:15 UTC · re: Junio C Hamano · lore

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

On 14 Dec 2008, Junio C. Hamano said:
Show 5 quoted lines
> 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.)

Sitaram Chamarty· Dec 15, 2008, 01:03 UTC · re: Nix · lore

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

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

Junio C Hamano· Dec 15, 2008, 01:27 UTC · re: Sitaram Chamarty · lore

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

Sitaram Chamarty <sitaramc@gmail.com> writes:
Show 9 quoted lines
> 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.

← back to recent threads