{"thread":{"id":"2836","subject":"RE: new file leaked onto release branch","startedAt":"2005-12-14T19:20:04Z","lastAt":"2005-12-18T07:08:40Z","messageCount":5,"participants":["Brown, Len","Linus Torvalds","Junio C Hamano","Tom Prince"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13627","messageId":"F7DC2337C7631D4386A2DF6E8FB22B30056B83F2@hdsmsx401.amr.corp.intel.com","threadId":"2836","inReplyTo":null,"subject":"RE: new file leaked onto release branch","fromName":"Brown, Len","fromEmail":"len.brown@intel.com","sentAt":"2005-12-14T19:20:04Z","receivedAt":"2005-12-14T19:20:04Z","isPatch":false,"sender":{"key":"len.brown@intel.com","avatar":"https://gravatar.com/avatar/a091f34f66caadb51d85a8a496800c6ccae73737e2f45762373e6b8c55fa5dd6?d=mp&s=160"},"body":" \n>So Len, since you seem to use \"git merge\" in your scripts, I \n>suspect you have an old version of git lying around. Can you try doing just\n\nShould I be using something different than git merge?\nis Documentation/howto/using-topic-branches out of date?\n\n>\tgit merge-base -a \n>0a47c906342e2447003e207d23917dfa5c912071 \n>d2149b542382bfc206cb28485108f6470c979566\n>\n>to see what the result is for you?\n\n$ git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566\nd2149b542382bfc206cb28485108f6470c979566\n\n>Also, maybe the _reason_ you have an old git lying around is \n>that you have two installations\n\nDoesn't appear to be the case, as I don't have a /usr/bin/git\nIIR, months ago I tried to install the rpm and\nit failed due to some incompatibility like not groking\na SuSE destination.  I got Dave's git tarball according\nto Jeff's howto: http://linux.yyz.us/git-howto.html\nand have been building and installing from a git repo since.\n(I found git-current tarball dated 7/21/05, so maybe it was then)\nI did, however a few months ago copy my i386 home directory over to the\nx86_64 box I use now, re-build and re-install.  Dunno\nif there may have been a hickup in that process...\nI found a backup copy of my i386 bin directory from 2005-08-25 --\nbinaries still in i386 format.  But I don't think I ran that b/c\nit isn't on any PATH.  Git lives in ~/bin which is 1st in my PATH.\n\nI think the lesson I'm taking away from this is that\nas I continue to stumble forward using git I should\nimmediately report anything that doesn't look quite right\nwhile I can still guarantee that all the clues are still\nat the scene of the crime.  I expect that I've re-built\nand re-installed git several times since the merge\nin question was made.\n\n-Len\n"},{"id":"13628","messageId":"Pine.LNX.4.64.0512141150210.3292@g5.osdl.org","threadId":"2836","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B30056B83F2@hdsmsx401.amr.corp.intel.com","subject":"RE: new file leaked onto release branch","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-14T20:10:47Z","receivedAt":"2005-12-14T20:10:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Dec 2005, Brown, Len wrote:\n>\n> >So Len, since you seem to use \"git merge\" in your scripts, I \n> >suspect you have an old version of git lying around. Can you try doing just\n> \n> Should I be using something different than git merge?\n\nNo, \"git merge\" should be fine. It's what \"git pull\" ends up doing \ninternally, which is why I suspected an old git version: \"git merge\" \nshould be well-tested, since it's very much what I end up using every day \nwhen I pull stuff.\n\n> >\tgit merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566\n> >\n> >to see what the result is for you?\n> \n> $ git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566\n> d2149b542382bfc206cb28485108f6470c979566\n\nOk, that's correct.\n\ngit-merge does:\n\n\tcommon=$(git-merge-base --all $head \"$@\")\n\nand then it _should_ have triggered this case:\n\n\tcase \"$#,$common,$no_commit\" in\n\t..\n\t1,\"$1\",*)\n\t\t# If head can reach all the merge then we are up to date.\n\t\t# but first the most common case of merging one remote\n\t\techo \"Already up-to-date.\"\n\t\tdropsave\n\t\texit 0\n\t\t;;\n\t..\n\nand thus never have created any merge messages.\n\nThat's what I get when I try this:\n\n\tgit checkout -b test-merge 0a47c906342e2447003e207d23917dfa5c912071\n\tgit merge \"Testing merging\" HEAD d2149b542382bfc206cb28485108f6470c979566\n\nresults in a very immediate\n\n\t\"Already up-to-date.\"\n\nmessage. Does it do that for you too?\n\nI tested not only with current git, but also the gits that were valid on \nNov 29 and Nov 30. All of them did this.\n\n> Doesn't appear to be the case, as I don't have a /usr/bin/git\n> IIR, months ago I tried to install the rpm and\n> it failed due to some incompatibility like not groking\n> a SuSE destination.  I got Dave's git tarball according\n> to Jeff's howto: http://linux.yyz.us/git-howto.html\n> and have been building and installing from a git repo since.\n> (I found git-current tarball dated 7/21/05, so maybe it was then)\n> I did, however a few months ago copy my i386 home directory over to the\n> x86_64 box I use now, re-build and re-install.  Dunno\n> if there may have been a hickup in that process...\n> I found a backup copy of my i386 bin directory from 2005-08-25 --\n> binaries still in i386 format.  But I don't think I ran that b/c\n> it isn't on any PATH.  Git lives in ~/bin which is 1st in my PATH.\n\nHmm. It really looks like it should have been impossible to generate that \ncommit with current git, which is why I'm still a bit suspicious. \n\n> I think the lesson I'm taking away from this is that\n> as I continue to stumble forward using git I should\n> immediately report anything that doesn't look quite right\n> while I can still guarantee that all the clues are still\n> at the scene of the crime.\n\nI think this list has been pretty responsive to reports of strange \nbehaviour, so yes. \n\n\t\t\tLinus\n"},{"id":"13629","messageId":"7virtrxv9c.fsf@assigned-by-dhcp.cox.net","threadId":"2836","inReplyTo":"F7DC2337C7631D4386A2DF6E8FB22B30056B83F2@hdsmsx401.amr.corp.intel.com","subject":"Re: new file leaked onto release branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-14T20:45:51Z","receivedAt":"2005-12-14T20:45:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brown, Len\" <len.brown@intel.com> writes:\n\n> Should I be using something different than git merge?\n> is Documentation/howto/using-topic-branches out of date?\n\nI reviewed it once again right now.  The document claims to be\nlast updated for 0.99.9f, but I do not see anything outdated in\nthere for the latest.  Tony's procedure looks valid [*1*], so do\nthe scripts you sent in this thread.\n\nSorry, but I do not seem to be able to spot anything obviously\nwrong with your troubled commits nor scripts.  I'll do some more\ndigging, including rewinding to an older git and trying them,\nbut I am pessimistic.\n\nI pointed out one anomaly which is the commit should never have\nbeen created because it was not even a fast forward but already\nup-to-date case, and it was followed up with exchange of a few\nmessages between Linus and you.  But even if we got that mixed\nup, the resulting merge should not have contained the file\nneither parents had.  That part worries me the most.\n\nOne question.  You mentioned these in your message, you have\na \"git.commit wrapper\" that contains these lines:\n\n    git-update-index --add --remove `quilt files`\n    git commit\n\nI am not familiar with 'quilt', but is \"quilt files\" the command\nto show the list of files with patches applied to the working\ntree?\n\nIf so, the above do tell git about the modified (including added\nor removed) files that the applied quilt patches touch, which\nsounds like the correct thing to do.\n\nBut the resulting commit from that procedure would not be a\nmerge commit, and the commit in question that had the rsinfo\nfile magically appeared from nowhere is a merge, so this does\nnot seem to have much to do with the current problem...\n\nStill puzzlled, sorry.\n\n\n[Footnote]\n\n*1* Except that the rsync transport is probably suboptimal for\npeople who stay reasonably up-to-date with Linus and I would\napply the following change if I were Tony, but that shouldn't\nhave anything to do with the trouble we are discussing here.\n\n---\ndiff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt\nindex 4698abe..4944297 100644\n--- a/Documentation/howto/using-topic-branches.txt\n+++ b/Documentation/howto/using-topic-branches.txt\n@@ -31,7 +31,7 @@ test tree and then pull to the release t\n patches blocked in the test tree waiting for complex changes to accumulate\n enough test time to graduate.\n \n-Back in the BitKeeper days I achieved this my creating small forests of\n+Back in the BitKeeper days I achieved this by creating small forests of\n temporary trees, one tree for each logical grouping of patches, and then\n pulling changes from these trees first to the test tree, and then to the\n release tree.  At first I replicated this in GIT, but then I realised\n@@ -42,7 +42,8 @@ So here is the step-by-step guide how th\n \n First create your work tree by cloning Linus's public tree:\n \n- $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work\n+ $ git clone \\\n+   master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work\n \n Change directory into the cloned tree you just created\n \n@@ -52,7 +53,7 @@ Set up a remotes file so that you can fe\n branch into a local branch named \"linus\":\n \n  $ cat > .git/remotes/linus\n- URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n+ URL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n  Pull: master:linus\n  ^D\n \n"},{"id":"13633","messageId":"20051214212612.GA24501@socrates","threadId":"2836","inReplyTo":"7virtrxv9c.fsf@assigned-by-dhcp.cox.net","subject":"Re: new file leaked onto release branch","fromName":"Tom Prince","fromEmail":"tom.prince@ualberta.net","sentAt":"2005-12-14T21:26:12Z","receivedAt":"2005-12-14T21:26:12Z","isPatch":false,"sender":{"key":"tom.prince@ualberta.net","avatar":"https://gravatar.com/avatar/a0ad19caee7618876339485106ec994f5202505eecd210ba5c0bd869feaa555a?d=mp&s=160"},"body":"On Wed, Dec 14, 2005 at 12:45:51PM -0800, Junio C Hamano wrote:\n> \n> I pointed out one anomaly which is the commit should never have\n> been created because it was not even a fast forward but already\n> up-to-date case, and it was followed up with exchange of a few\n> messages between Linus and you.\n> \n\nI don't remember any of the details now, but I remember that an old\nversion of git or cogito would create bogus fast-forward merges, if they\nwere used without GNU coreutils. The machine it happend on was running\nFreeBSD 4.10, but current versions work fine.\n\n  Tom\n"},{"id":"13779","messageId":"7vhd96ubk7.fsf@assigned-by-dhcp.cox.net","threadId":"2836","inReplyTo":"Pine.LNX.4.64.0512141150210.3292@g5.osdl.org","subject":"Re: new file leaked onto release branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-18T07:08:40Z","receivedAt":"2005-12-18T07:08:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> git-merge does:\n>\n> \tcommon=$(git-merge-base --all $head \"$@\")\n>\n> and then it _should_ have triggered this case:\n>\n> \tcase \"$#,$common,$no_commit\" in\n> \t..\n> \t1,\"$1\",*)\n> \t\t# If head can reach all the merge then we are up to date.\n> \t\t# but first the most common case of merging one remote\n> \t\techo \"Already up-to-date.\"\n> \t\tdropsave\n> \t\texit 0\n> \t\t;;\n> \t..\n>\n> and thus never have created any merge messages.\n>...\n> Hmm. It really looks like it should have been impossible to generate that \n> commit with current git, which is why I'm still a bit suspicious. \n\nTwo good news (one puzzle fully explained, one bug fixed) and\none not so good news (one puzzle still remains).\n\nFirst good news.  I solved this puzzle.  This has been fixed as\na part of a seemingly independent fix:\n\n    commit 9954f5b876abb6118f9bdf1d113239d86acca7bd\n    Author: Junio C Hamano <junkio@cox.net>\n    Date:   Tue Dec 13 17:01:23 2005 -0800\n\n        [PATCH] allow merging any committish\n\n        Although \"git-merge\" is advertised as the end-user level command\n        (instead of being a \"git-pull\" backend), it was not prepared to\n        take tag objects that point at commits and barfed when fed one.\n        Sanitize the input while we validate them, for which we already\n        have a loop.\n\n        Signed-off-by: Junio C Hamano <junkio@cox.net>\n\nThere was a bug in git-merge which used the user input without\nconverting them to object names.  When the part you quoted above\nwas executed, $1..${$#} were remote ref parameters from the\ncommand line, so in the case of Len's commit, which did:\n\n      git merge \"Auto-update from upstream\" release linus\n\n\"$1\" at that point was string \"linus\", not the object name\nreturned from \"git-rev-parse --verify linus\".  The case pattern\nmatch did not match because $common was object name and $1 was\nnot.  This was fixed by the above commit; the user supplied refs\nare already converted into object names at that point with the\ncurrent code.\n\nI have never seen this problem myself because git-pull feeds\nobject names after converting refnames to git-merge, but people\nwho used the git-merge command themselves could have been\naffected by the bug.\n\nSo I think I am done with the \"this is \"already-up-to-date\"; why\ndoes that commit exists in the first place?\" commit we have\ndiscussed in this thread.\n\nSecond good news.  I have been working on a theory on the \"where\ndid this file come from?\" problem.  I found a real bug that can\ncause a bad mismerge that can introduce completely unrelated\nchanges to the tree, but after digging a bit deeper, I do not\nthink it matches Len's problematic commit.  It still is a bug.\n\nIf you run the sequence attached at the end in an empty\nrepository, you will have a repository suitable for this\ndemonstration.  After the script runs, the commit structure\nwould look like this:\n\n! [heads/7589] add xyzzy\n * [master] Merge 7589 branch\n  ! [nitfol] add nitfol\n---\n+   [8eec60c] add xyzzy\t\t\t<tag 7589>\n +  [db5bc99] edit frotz\n  + [758916c] add nitfol\n+++ [70c4319] initial\n\nThere are three branches: master, nitfol, and \"7589\".\nThey all start from the initial commit which has one file\n\"frotz\" and each branch adds one commit.  Also the tip of 7589\nbranch is tagged as \"7589\".  Now, we will run this:\n\n\t$ git merge \"Merge 7589 branch\" HEAD 7589\n\nWith this setup, the current tip of the \"master\" branch\nmismerges and adds \"nitfol\" file which did not exist in either\nbranch heads (and it is not fixed with the 9954f5 commit above).\n\nA change I introduced mid November causes get_sha1_basic() to\nmisinterpret \"7589\" to be neither the tag 7589 nor branch 7589\ntip, but by mistake it does not outright fail, but returns the\n758916c commit!  This merge ends up pulling nitfol branch head\ninto master branch, not 7589 branch as the user intended.  The\nresulting merge commit has db5bc99 and 758916c as its parents.\n\nThe \"revert misguided disambiguation\" patch I posted earlier\nfixes this problem.  I'll push it out tonight.\n\nThis theory however does not seem to match what really happened.\nLen did mention that he has \"5165\" branch (there is a commit\nmarked \"Pull 5165 into release branch\" near a problematic\nmerge), but he did not say he also has a 5165 tag; the bug does\nnot trigger if you do not have the tag of the same name.  Also\nif this theory holds true, the problematic commit should have a\ncommit whose object name begins with 5165 as the second parent\nbut that is not the case.  And the problem happened with a\ncommit that is not a merge between release/test and topic\nbranch anyway; it is with an \"Auto-update from upstream\" commit.\n\nSo I am still puzzled by the \"where did this file come from\"\nproblem.  The most plausible explanation was the driver error\nmentioned already in the thread: \"update-index --add\" in the\nmiddle of merge with manual committing.\n\n----------------------------------------------------------------\n#!/bin/sh\n\nGIT_AUTHOR_DATE='1995-01-29T15:00:00 -0800'\nGIT_AUTHOR_EMAIL='author@example.com'\nGIT_AUTHOR_NAME='A U Thor'\nGIT_COMMITTER_DATE='1995-01-29T15:00:00 -0800'\nGIT_COMMITTER_EMAIL='committer@example.com'\nGIT_COMMITTER_NAME='C O Mmitter'\n\nexport GIT_AUTHOR_DATE\nexport GIT_AUTHOR_EMAIL\nexport GIT_AUTHOR_NAME\nexport GIT_COMMITTER_DATE\nexport GIT_COMMITTER_EMAIL\nexport GIT_COMMITTER_NAME\n\ngit init-db\n\necho frotz >frotz\ngit add frotz\ngit commit -m 'initial'\n\ngit checkout -b nitfol\necho nitfol >nitfol\ngit add nitfol\ngit commit -m 'add nitfol'\n\ngit checkout -b 7589 master\necho xyzzy >xyzzy\ngit add xyzzy\ngit commit -m 'add xyzzy'\ngit tag 7589\n\ngit checkout master\necho FROTZ >frotz\ngit update-index frotz\ngit commit -m 'edit frotz'\n"}]}