# new file leaked onto release branch 5 messages from 2005-12-14 to 2005-12-14. Participants: Len Brown, Junio C Hamano, Linus Torvalds. Thread: https://gitlist.dev/t/2830 ## Len Brown, 2005-12-14 07:57 Subject: new file leaked onto release branch Message-ID: <200512140257.03975.len.brown@intel.com> URL: https://gitlist.dev/e/200512140257.03975.len.brown%40intel.com ``` I'm suspecting that this issue is technically a pilot error of me issuing git-updated-index at the wrong time, but perhaps the list should be aware of this type of issue. And perhaps somebody can suggest a better work flow that is immune to this? Somehow a new file leaked from my "acpica" branch onto my "release" branch without me pulling "acpica" into "release". I use the latest git and I follow Tony's Documentation/howto/using-topic-branches.txt. The new file, rsinfo.c, was added in one of the patches in the acpi branch, but then was sucked into the release branch in this commit: 9115a6c787596e687df03010d97fccc5e0762506 which is on the release.broken branch of this tree: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git Even though the file didn't exist on either of the parents of the merge. I think I probably did a git-update-index while working on the acpica branch, and then git remembered that while I was on the release branch doing a routine pull from linus to make sure I was up-to-date before doing a push to kernel.org. why did I do this? I use quilt to manage a stack of patches in my repo. I like to build them on several build machines (i386, x86_64, ia64) before doing a git commit. I package up a tar-file for the remote machines with git-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE But I still need to generate a patch containing all the local changes that I haven't checked into git yet. git diff > my.patch does this for me. But when it failed to pick up a new file, I manually did a git-update-index --add IIR, and that seems to be how rsinfo.c got sucked into the subsequent git pull from linus. perhaps somebody has a better idiom for packaging up a current working tree for a remote build machine to crunch on it? thanks, -Len ``` ## Junio C Hamano, 2005-12-14 08:37 Subject: Re: new file leaked onto release branch Message-ID: <7v3bkw2hxl.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v3bkw2hxl.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200512140257.03975.len.brown@intel.com> ``` Len Brown writes: > Somehow a new file leaked from my "acpica" branch onto my "release" branch > without me pulling "acpica" into "release". I'll take a look at your "broken" branch later today (but will go to bed first ;-), so please leave it around. > I package up a tar-file for the remote machines with > git-tar-tree $BRANCH $REPO | gzip -1 > $TARFILE > But I still need to generate a patch containing all the local > changes that I haven't checked into git yet. Let me understand what you have correctly: You have the latest commit, changes needed to be tested in working tree, and index is somewhere in-between, because of "git-update-index --add" you did for patch generation; but ideally you would want to keep HEAD and index in sync. And you need a way to do the above tar-tree + patch equivanent to move what you have in your working tree to other machines for pre-commit testing. Some random thoughts on ways to do it. (1) NFS with "make O=dir/to/store/output/files/"? (2) Do you have git on other build boxes? Perhaps mainbox$ edit on "acpica" branch mainbox$ git checkout -b build-test ;# branch from it mainbox$ git add some files mainbox$ git commit -a -m "Build test $(date)" ;# take all mainbox$ ssh i386box i386box$ git pull mainbox:/home/lnx/.git build-test Fast forward. i386box$ make ;# happy mainbox$ git checkout acpica ; git pull . build-test ;# fast forward (3) Tarball approach, but taking the local modifications along as well: mainbox$ git update-index all-changed-paths-not-just-add mainbox$ git-tar-tree $(git-write-tree) $REPO | gzip >$TARFILE mainbox$ git reset ;# unregisters all mods since HEAD from index mainbox$ scp $TARFILE i386box:/home/lnx/ I suspect the last one is the least disruptive to your existing workflow. ``` ## Junio C Hamano, 2005-12-14 09:39 Subject: Re: new file leaked onto release branch Message-ID: <7vmzj4yq3l.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vmzj4yq3l.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200512140257.03975.len.brown@intel.com> ``` Len Brown writes: > I'm suspecting that this issue is technically a pilot error of me issuing > git-updated-index at the wrong time, but perhaps the list > should be aware of this type of issue. Merging is so fundamental to git workflow, and it is not supposed to be prone to pilot errors, so I am puzzled and very worried, so I am still awake. Even if you added some file to the index prior to merge, this sequence: $ git checkout one-branch $ git add some-file $ git pull . another-branch should *never* succeed. It should always fail, saying: fatal: Entry 'some-file' would be overwritten by merge. Cannot merge. and I just tried it with both recursive (default) and resolve merge strategies. They both do the right thing. One exception is if you did something like this: $ git checkout one-branch $ git pull . another-branch ;# oops, merge conflicts! $ edit conflicted files and fix $ git update-index --add some-file $ git commit You can introduce unrelated changes to commits like that. Lemme see what your release.broken looks like. Gahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh. Forget about what I said. Although all of what I said above are correct, I do not think it applies to your case at all --- these commits do not appear to be created by git-pull nor git-merge, and honestly, they look quite bogus. There is something else going on. $ git cat-file commit 9115a6 tree da65904b8c0c0bc6c778b39bc25d06e07ca7c82c parent 927fe18397b3b1194a5b26b1d388d97e391e5fd2 parent e4f5c82a92c2a546a16af1614114eec19120e40a author Len Brown 1133904460 -0500 committer Len Brown 1133904460 -0500 Auto-update from upstream $ git-merge-base 9115a6^1 9115a6^2; git-rev-parse 9115a6^2 e4f5c82a92c2a546a16af1614114eec19120e40a e4f5c82a92c2a546a16af1614114eec19120e40a What is this "Auto-update from upstream" merge? It is not a merge at all, not even a fast forward. Your branch tip was 927fe1 and the other branch tip e4f5c8 was behind. In fact, I just tried it and both of my attempts correctly said "Already up-to-date.", with or without local changes to the index. $ git show-branch --sha1-name --topo-order lenb/merge* * [lenb/mergetest] Pull 5165 into release branch ! [lenb/mergeother] V4L/DVB (3087) fix analog NTSC for pcHDTV 3000 -- + [927fe18] Pull 5165 into release branch + [1e48396] [ACPI] correct earlier SMP deep C-states on HT patch ++ [e4f5c82] V4L/DVB (3087) fix analog NTSC for pcHDTV 3000 $ git pull . lenb/mergeother Already up-to-date. What do you use to create these "Auto-update" commits? I think 9115a6 commit should not *even* *exist*. The merge between 927fe1 and e4f5c8 should have resulted in "Oh, we are already up-to-date and they are behind, so there is nothing for us to do". Or if your tool somehow records your tree as the second parent (goes against the usual convention but is a valid thing to do), it should have resulted in "Updating from e4f5c8... to 927fe1. Fast forward". In either case, 9115a6 commit should never have been created in the first place. What do you use to create these "Auto-update" commits, and how can I help you to fix it? ``` ## Linus Torvalds, 2005-12-14 16:26 Subject: Re: new file leaked onto release branch Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0512140822540.3292%40g5.osdl.org In-Reply-To: <7vmzj4yq3l.fsf@assigned-by-dhcp.cox.net> ``` On Wed, 14 Dec 2005, Junio C Hamano wrote: > > Gahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh. > > Forget about what I said. Although all of what I said above are > correct, I do not think it applies to your case at all --- these > commits do not appear to be created by git-pull nor git-merge, > and honestly, they look quite bogus. There is something else > going on. > > $ git cat-file commit 9115a6 > tree da65904b8c0c0bc6c778b39bc25d06e07ca7c82c > parent 927fe18397b3b1194a5b26b1d388d97e391e5fd2 > parent e4f5c82a92c2a546a16af1614114eec19120e40a > author Len Brown 1133904460 -0500 > committer Len Brown 1133904460 -0500 > > Auto-update from upstream > > $ git-merge-base 9115a6^1 9115a6^2; git-rev-parse 9115a6^2 > e4f5c82a92c2a546a16af1614114eec19120e40a > e4f5c82a92c2a546a16af1614114eec19120e40a Argh. Len, how old a git are you using? "git-merge" really should _never_ have done this, but old (and I mean really old) git merges sometimes got confused with the base parent and would create a merge even when it was unnecessary. Linus ``` ## Linus Torvalds, 2005-12-14 16:53 Subject: Re: new file leaked onto release branch Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0512140837160.3292%40g5.osdl.org In-Reply-To: ``` On Wed, 14 Dec 2005, Linus Torvalds wrote: > > Argh. > > Len, how old a git are you using? "git-merge" really should _never_ have > done this, but old (and I mean really old) git merges sometimes got > confused with the base parent and would create a merge even when it was > unnecessary. Going through the real kernel tree, this has happened before: commit 8e9887cc3b8d9f1c88c6f3842346a9478e52718f Merge: 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566 Author: Len Brown Date: Wed Nov 30 22:22:52 2005 -0500 Auto-update from upstream and doing a git-merge-base -a 0a47c906342 d2149b542 results in the second parent: d2149b542382bfc206cb28485108f6470c979566. We also have two old ones: commit b129a8ccd53f74c43e4c83c8e0031a4990040830 commit 603fff54420a0ccc4c3b48bfef43896fb4e33161 but both of those are from June, and of known causes (Russell King using an old git that didn't clean up after a failed merge, and he ended up committing a perfectly normal change as a bogus merge because git would remember that broken MERGE_HEAD). So Len, since you seem to use "git merge" in your scripts, I suspect you have an old version of git lying around. Can you try doing just git merge-base -a 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566 to see what the result is for you? Also, maybe the _reason_ you have an old git lying around is that you have two installations - if you have at some point installed both an RPM _and_ recompiled your own git, you may have different git versions in ~/bin and in /usr/bin, and then depending on how you log in to the machine, you may end up with different versions being used.. Linus ```