# Possibly-spurious 'not uptodate. Cannot merge' 5 messages from 2008-12-14 to 2008-12-15. Participants: Nix, Junio C Hamano, Sitaram Chamarty. Thread: https://gitlist.dev/t/16727 ## Nix, 2008-12-14 16:47 Subject: Possibly-spurious 'not uptodate. Cannot merge' Message-ID: <874p16puuq.fsf@hades.wkstn.nix> URL: https://gitlist.dev/e/874p16puuq.fsf%40hades.wkstn.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?) ``` ## Junio C Hamano, 2008-12-14 19:33 Subject: Re: Possibly-spurious 'not uptodate. Cannot merge' Message-ID: <7vwse21rh6.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vwse21rh6.fsf%40gitster.siamese.dyndns.org In-Reply-To: <874p16puuq.fsf@hades.wkstn.nix> ``` Nix 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 ;-) ``` ## Nix, 2008-12-14 23:15 Subject: Re: Possibly-spurious 'not uptodate. Cannot merge' Message-ID: <87bpve73ic.fsf@hades.wkstn.nix> URL: https://gitlist.dev/e/87bpve73ic.fsf%40hades.wkstn.nix In-Reply-To: <7vwse21rh6.fsf@gitster.siamese.dyndns.org> ``` 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.) ``` ## Sitaram Chamarty, 2008-12-15 01:03 Subject: Re: Possibly-spurious 'not uptodate. Cannot merge' Message-ID: URL: https://gitlist.dev/e/gi4adq%24cr1%241%40ger.gmane.org In-Reply-To: <874p16puuq.fsf@hades.wkstn.nix> ``` On 2008-12-14, Nix 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, 2008-12-15 01:27 Subject: Re: Possibly-spurious 'not uptodate. Cannot merge' Message-ID: <7vy6yiz0pw.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vy6yiz0pw.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Sitaram Chamarty writes: > On 2008-12-14, Nix 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. ```