{"thread":{"id":"16727","subject":"Possibly-spurious 'not uptodate. Cannot merge'","startedAt":"2008-12-14T16:47:09Z","lastAt":"2008-12-15T01:27:55Z","messageCount":5,"participants":["Nix","Junio C Hamano","Sitaram Chamarty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"97886","messageId":"874p16puuq.fsf@hades.wkstn.nix","threadId":"16727","inReplyTo":null,"subject":"Possibly-spurious 'not uptodate. Cannot merge'","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2008-12-14T16:47:09Z","receivedAt":"2008-12-14T16:47:09Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get\nthis:\n\nloki 504 /usr/packages/linux/linux% git pull\nremote: Counting objects: 638, done.\nremote: Compressing objects: 100% (86/86), done.\nremote: Total 517 (delta 430), reused 516 (delta 430)\nReceiving objects: 100% (517/517), 74.91 KiB, done.\nResolving deltas: 100% (430/430), completed with 120 local objects.\nFrom git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y\n 078bb16..5defaf8 master -> 2.6.27-stable/master\n * [new tag] v2.6.27.9 -> v2.6.27.9\nerror: Entry 'Makefile' not uptodate. Cannot merge.\nfatal: merging of trees 34f70ec1fadcaad7de6979491e2dea9da735e6f9 and ded3f44559ce050e0ef014ebce093c5d9295ede8 failed\nMerge with strategy recursive failed.\n\nIn this situation, 'git diff' reports no changes at all, but 'git reset\n--hard' gets the tree back into a state where merging succeeds, as does\n'git update-index --refresh'.\n\nI suspect the 'problem' is that I've hardlinked a bunch of build trees\nto this tree in the interim via 'cp -al', then applied patches to each\nof those trees with quilt, then deleted all those trees prior to the git\npull. This doesn't change the original files at all, but *does* update\ntheir link count: is git getting annoyed by the corresponding change in\nctime? (If so, why did it start happening only fairly recently?)\n"},{"id":"97891","messageId":"7vwse21rh6.fsf@gitster.siamese.dyndns.org","threadId":"16727","inReplyTo":"874p16puuq.fsf@hades.wkstn.nix","subject":"Re: Possibly-spurious 'not uptodate. Cannot merge'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-14T19:33:57Z","receivedAt":"2008-12-14T19:33:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nix writes:\n\n> Recently (as of perhaps git 1.5.4?), whenever I update my l-k tree I get\n> this:\n> ...\n> I suspect the 'problem' is that I've hardlinked a bunch of build trees\n> to this tree in the interim via 'cp -al', then applied patches to each\n> of those trees with quilt, then deleted all those trees prior to the git\n> pull. This doesn't change the original files at all, but *does* update\n> their link count: is git getting annoyed by the corresponding change in\n> ctime? (If so, why did it start happening only fairly recently?)\n\nIn git timescale 1.5.4 is not recent at all ;-)\n\nAncient git, whose \"git merge\" was a scripted command, refreshed the index\nbefore starting, but it lost that when the command was rewritten in C soon\nafter v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed\nit until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09). In other\nwords, the tip of 'master' (and upcoming 1.6.1) already has the fix.\n\nThe fix should have been cherry-picked to 'maint' to be part of 1.6.0.X\nseries, but it apparently was forgotten. Fault of mine and Shawn ;-)\n"},{"id":"97898","messageId":"87bpve73ic.fsf@hades.wkstn.nix","threadId":"16727","inReplyTo":"7vwse21rh6.fsf@gitster.siamese.dyndns.org","subject":"Re: Possibly-spurious 'not uptodate. Cannot merge'","fromName":"Nix","fromEmail":"nix@esperi.org.uk","sentAt":"2008-12-14T23:15:07Z","receivedAt":"2008-12-14T23:15:07Z","isPatch":false,"sender":{"key":"nix@esperi.org.uk","avatar":"https://avatars.githubusercontent.com/u/6503005?v=4"},"body":"On 14 Dec 2008, Junio C. Hamano said:\n> Ancient git, whose \"git merge\" was a scripted command, refreshed the index\n> before starting, but it lost that when the command was rewritten in C soon\n> after v1.5.6 by 1c7b76b (Build in merge, 2008-07-07), and nobody noticed\n> it until 76c3fb1 (Merge branch 'mv/merge-refresh', 2008-10-09). In other\n> words, the tip of 'master' (and upcoming 1.6.1) already has the fix.\n\nExcellent! I do love this precognitive bugfixing thing.\n\n(It's not as if the update-index workaround is terribly onerous, but\nit's annoying and not something a git newbie might think of.)\n"},{"id":"97914","messageId":"gi4adq$cr1$1@ger.gmane.org","threadId":"16727","inReplyTo":"874p16puuq.fsf@hades.wkstn.nix","subject":"Re: Possibly-spurious 'not uptodate. Cannot merge'","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2008-12-15T01:03:54Z","receivedAt":"2008-12-15T01:03:54Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 2008-12-14, Nix wrote:\n> In this situation, 'git diff' reports no changes at all, but 'git reset\n> --hard' gets the tree back into a state where merging succeeds, as does\n> 'git update-index --refresh'.\n\nWasn't there some situation in which merely running 'git\nstatus' would have a similar effect? I seem to recall\nreading that somewhere but now I can't find any mention of\nit in 'git help status'.\n"},{"id":"97918","messageId":"7vy6yiz0pw.fsf@gitster.siamese.dyndns.org","threadId":"16727","inReplyTo":"gi4adq$cr1$1@ger.gmane.org","subject":"Re: Possibly-spurious 'not uptodate. Cannot merge'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-15T01:27:55Z","receivedAt":"2008-12-15T01:27:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sitaram Chamarty writes:\n\n> On 2008-12-14, Nix wrote:\n>> In this situation, 'git diff' reports no changes at all, but 'git reset\n>> --hard' gets the tree back into a state where merging succeeds, as does\n>> 'git update-index --refresh'.\n>\n> Wasn't there some situation in which merely running 'git\n> status' would have a similar effect? I seem to recall\n> reading that somewhere but now I can't find any mention of\n> it in 'git help status'.\n\nIt would, but this is a pure bug in the re-implementation of git-merge\nthat was introduced soon after v1.5.6. The users shouldn't be required to\nrun refresh to work this around.\n"}]}