{"thread":{"id":"2830","subject":"new file leaked onto release branch","startedAt":"2005-12-14T07:57:03Z","lastAt":"2005-12-14T16:53:38Z","messageCount":5,"participants":["Len Brown","Junio C Hamano","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13609","messageId":"200512140257.03975.len.brown@intel.com","threadId":"2830","inReplyTo":null,"subject":"new file leaked onto release branch","fromName":"Len Brown","fromEmail":"len.brown@intel.com","sentAt":"2005-12-14T07:57:03Z","receivedAt":"2005-12-14T07:57:03Z","isPatch":false,"sender":{"key":"len.brown@intel.com","avatar":"https://gravatar.com/avatar/a091f34f66caadb51d85a8a496800c6ccae73737e2f45762373e6b8c55fa5dd6?d=mp&s=160"},"body":"I'm suspecting that this issue is technically a pilot error of me issuing\ngit-updated-index at the wrong time, but perhaps the list\nshould be aware of this type of issue.  And perhaps somebody\ncan suggest a better work flow that is immune to this?\n\nSomehow a new file leaked from my \"acpica\" branch onto my \"release\" branch\nwithout me pulling \"acpica\" into \"release\".\n\nI use the latest git and I follow Tony's Documentation/howto/using-topic-branches.txt.\n\nThe new file, rsinfo.c,  was added in one of the patches in the acpi branch,\nbut then was sucked into the release branch in this commit:\n9115a6c787596e687df03010d97fccc5e0762506\nwhich is on the release.broken branch of this tree:\ngit://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git\n\nEven though the file didn't exist on either of the parents of the merge.\n\nI think I probably did a git-update-index while working on the acpica\nbranch, and then git remembered that while I was on the release branch\ndoing a routine pull from linus to make sure I was up-to-date before\ndoing a push to kernel.org.\n\nwhy did I do this?\n\nI use quilt to manage a stack of patches in my repo.\nI like to build them on several build machines (i386, x86_64, ia64)\nbefore doing a git commit.\n\nI package up a tar-file for the remote machines with\ngit-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE\nBut I still need to generate a patch containing all the local\nchanges that I haven't checked into git yet.\n\ngit diff > my.patch\ndoes this for me.  But when it failed to pick up a new file,\nI manually did a git-update-index --add IIR, and that seems\nto be how rsinfo.c got sucked into the subsequent git pull from linus.\n\nperhaps somebody has a better idiom for packaging up a  current\nworking tree for a remote build machine to crunch on it?\n\nthanks,\n-Len\n"},{"id":"13610","messageId":"7v3bkw2hxl.fsf@assigned-by-dhcp.cox.net","threadId":"2830","inReplyTo":"200512140257.03975.len.brown@intel.com","subject":"Re: new file leaked onto release branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-14T08:37:10Z","receivedAt":"2005-12-14T08:37:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Len Brown <len.brown@intel.com> writes:\n\n> Somehow a new file leaked from my \"acpica\" branch onto my \"release\" branch\n> without me pulling \"acpica\" into \"release\".\n\nI'll take a look at your \"broken\" branch later today (but will\ngo to bed first ;-), so please leave it around.\n\n> I package up a tar-file for the remote machines with\n> git-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE\n> But I still need to generate a patch containing all the local\n> changes that I haven't checked into git yet.\n\nLet me understand what you have correctly:\n\n    You have the latest commit, changes needed to be tested in\n    working tree, and index is somewhere in-between, because of\n    \"git-update-index --add\" you did for patch generation; but\n    ideally you would want to keep HEAD and index in sync.\n\nAnd you need a way to do the above tar-tree + patch equivanent\nto move what you have in your working tree to other machines for\npre-commit testing.  Some random thoughts on ways to do it.\n\n(1) NFS with \"make O=dir/to/store/output/files/\"?\n\n(2) Do you have git on other build boxes?  Perhaps\n\n    mainbox$ edit on \"acpica\" branch\n    mainbox$ git checkout -b build-test ;# branch from it\n    mainbox$ git add some files\n    mainbox$ git commit -a -m \"Build test $(date)\" ;# take all\n\n    mainbox$ ssh i386box\n    i386box$ git pull mainbox:/home/lnx/.git build-test\n    Fast forward.\n    i386box$ make ;# happy\n\n    mainbox$ git checkout acpica ; git pull . build-test ;# fast forward\n\n(3) Tarball approach, but taking the local modifications along\n    as well:\n\n    mainbox$ git update-index all-changed-paths-not-just-add\n    mainbox$ git-tar-tree $(git-write-tree) $REPO | gzip >$TARFILE\n    mainbox$ git reset ;# unregisters all mods since HEAD from index\n    mainbox$ scp $TARFILE i386box:/home/lnx/\n\nI suspect the last one is the least disruptive to your existing\nworkflow.\n"},{"id":"13612","messageId":"7vmzj4yq3l.fsf@assigned-by-dhcp.cox.net","threadId":"2830","inReplyTo":"200512140257.03975.len.brown@intel.com","subject":"Re: new file leaked onto release branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-14T09:39:42Z","receivedAt":"2005-12-14T09:39:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Len Brown <len.brown@intel.com> writes:\n\n> I'm suspecting that this issue is technically a pilot error of me issuing\n> git-updated-index at the wrong time, but perhaps the list\n> should be aware of this type of issue.\n\nMerging is so fundamental to git workflow, and it is not\nsupposed to be prone to pilot errors, so I am puzzled and\nvery worried, so I am still awake.\n\nEven if you added some file to the index prior to merge, this\nsequence:\n\n        $ git checkout one-branch\n        $ git add some-file\n        $ git pull . another-branch\n\nshould *never* succeed.  It should always fail, saying:\n\n        fatal: Entry 'some-file' would be overwritten by merge. Cannot merge.\n\nand I just tried it with both recursive (default) and resolve\nmerge strategies.  They both do the right thing.\n\nOne exception is if you did something like this:\n\n\t$ git checkout one-branch\n        $ git pull . another-branch ;# oops, merge conflicts!\n        $ edit conflicted files and fix\n        $ git update-index --add some-file\n        $ git commit\n\nYou can introduce unrelated changes to commits like that.  Lemme\nsee what your release.broken looks like.\n\nGahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh.\n\nForget about what I said.  Although all of what I said above are\ncorrect, I do not think it applies to your case at all --- these\ncommits do not appear to be created by git-pull nor git-merge,\nand honestly, they look quite bogus.  There is something else\ngoing on.\n\n        $ git cat-file commit 9115a6\n        tree da65904b8c0c0bc6c778b39bc25d06e07ca7c82c\n        parent 927fe18397b3b1194a5b26b1d388d97e391e5fd2\n        parent e4f5c82a92c2a546a16af1614114eec19120e40a\n        author Len Brown <len.brown@intel.com> 1133904460 -0500\n        committer Len Brown <len.brown@intel.com> 1133904460 -0500\n\n        Auto-update from upstream\n\n        $ git-merge-base 9115a6^1 9115a6^2; git-rev-parse 9115a6^2\n        e4f5c82a92c2a546a16af1614114eec19120e40a\n        e4f5c82a92c2a546a16af1614114eec19120e40a\n\nWhat is this \"Auto-update from upstream\" merge?  It is not a\nmerge at all, not even a fast forward.  Your branch tip was\n927fe1 and the other branch tip e4f5c8 was behind.  In fact, I\njust tried it and both of my attempts correctly said \"Already\nup-to-date.\", with or without local changes to the index.\n\n        $ git show-branch --sha1-name --topo-order lenb/merge*\n        * [lenb/mergetest] Pull 5165 into release branch\n         ! [lenb/mergeother] V4L/DVB (3087) fix analog NTSC for pcHDTV 3000\n        --\n        +  [927fe18] Pull 5165 into release branch\n        +  [1e48396] [ACPI] correct earlier SMP deep C-states on HT patch\n        ++ [e4f5c82] V4L/DVB (3087) fix analog NTSC for pcHDTV 3000\n\n        $ git pull . lenb/mergeother\n        Already up-to-date.\n\nWhat do you use to create these \"Auto-update\" commits?\n\nI think 9115a6 commit should not *even* *exist*.  The merge\nbetween 927fe1 and e4f5c8 should have resulted in \"Oh, we are\nalready up-to-date and they are behind, so there is nothing for\nus to do\".\n\nOr if your tool somehow records your tree as the second parent\n(goes against the usual convention but is a valid thing to do),\nit should have resulted in \"Updating from e4f5c8... to 927fe1.\nFast forward\".\n\nIn either case, 9115a6 commit should never have been created in\nthe first place.\n\nWhat do you use to create these \"Auto-update\" commits, and how\ncan I help you to fix it?\n"},{"id":"13620","messageId":"Pine.LNX.4.64.0512140822540.3292@g5.osdl.org","threadId":"2830","inReplyTo":"7vmzj4yq3l.fsf@assigned-by-dhcp.cox.net","subject":"Re: new file leaked onto release branch","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-14T16:26:14Z","receivedAt":"2005-12-14T16:26:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Dec 2005, Junio C Hamano wrote:\n> \n> Gahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh.\n> \n> Forget about what I said.  Although all of what I said above are\n> correct, I do not think it applies to your case at all --- these\n> commits do not appear to be created by git-pull nor git-merge,\n> and honestly, they look quite bogus.  There is something else\n> going on.\n> \n>         $ git cat-file commit 9115a6\n>         tree da65904b8c0c0bc6c778b39bc25d06e07ca7c82c\n>         parent 927fe18397b3b1194a5b26b1d388d97e391e5fd2\n>         parent e4f5c82a92c2a546a16af1614114eec19120e40a\n>         author Len Brown <len.brown@intel.com> 1133904460 -0500\n>         committer Len Brown <len.brown@intel.com> 1133904460 -0500\n> \n>         Auto-update from upstream\n> \n>         $ git-merge-base 9115a6^1 9115a6^2; git-rev-parse 9115a6^2\n>         e4f5c82a92c2a546a16af1614114eec19120e40a\n>         e4f5c82a92c2a546a16af1614114eec19120e40a\n\nArgh. \n\nLen, how old a git are you using? \"git-merge\" really should _never_ have \ndone this, but old (and I mean really old) git merges sometimes got \nconfused with the base parent and would create a merge even when it was \nunnecessary.\n\n\t\tLinus\n"},{"id":"13623","messageId":"Pine.LNX.4.64.0512140837160.3292@g5.osdl.org","threadId":"2830","inReplyTo":"Pine.LNX.4.64.0512140822540.3292@g5.osdl.org","subject":"Re: new file leaked onto release branch","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-12-14T16:53:38Z","receivedAt":"2005-12-14T16:53:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 14 Dec 2005, Linus Torvalds wrote:\n> \n> Argh. \n> \n> Len, how old a git are you using? \"git-merge\" really should _never_ have \n> done this, but old (and I mean really old) git merges sometimes got \n> confused with the base parent and would create a merge even when it was \n> unnecessary.\n\nGoing through the real kernel tree, this has happened before:\n\n\tcommit 8e9887cc3b8d9f1c88c6f3842346a9478e52718f\n\tMerge: 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566\n\tAuthor: Len Brown <len.brown@intel.com>\n\tDate:   Wed Nov 30 22:22:52 2005 -0500\n\t\n\t    Auto-update from upstream\n\nand doing a\n\n\tgit-merge-base -a 0a47c906342 d2149b542\n\nresults in the second parent: d2149b542382bfc206cb28485108f6470c979566.\n\nWe also have two old ones:\n\n\tcommit b129a8ccd53f74c43e4c83c8e0031a4990040830\n\tcommit 603fff54420a0ccc4c3b48bfef43896fb4e33161\n\nbut both of those are from June, and of known causes (Russell King using \nan old git that didn't clean up after a failed merge, and he ended up \ncommitting a perfectly normal change as a bogus merge because git would \nremember that broken MERGE_HEAD).\n\nSo Len, since you seem to use \"git merge\" in your scripts, I suspect you \nhave an old version of git lying around. Can you try doing just\n\n\tgit merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566\n\nto see what the result is for you?\n\nAlso, maybe the _reason_ you have an old git lying around is that you have \ntwo installations - if you have at some point installed both an RPM _and_ \nrecompiled your own git, you may have different git versions in ~/bin and \nin /usr/bin, and then depending on how you log in to the machine, you may \nend up with different versions being used..\n\n\t\t\tLinus\n"}]}