new file leaked onto release branch

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

Len Brown <len.brown@intel.com> writes:

I'll take a look at your "broken" branch later today (but will go to bed first ;-), so please leave it around.

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.

Len Brown <len.brown@intel.com> writes:

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 <len.brown@intel.com> 1133904460 -0500
        committer Len Brown <len.brown@intel.com> 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?

On Wed, 14 Dec 2005, Junio C Hamano 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.

		Linus

On Wed, 14 Dec 2005, Linus Torvalds wrote:

Going through the real kernel tree, this has happened before:

	commit 8e9887cc3b8d9f1c88c6f3842346a9478e52718f
	Merge: 0a47c906342e2447003e207d23917dfa5c912071 d2149b542382bfc206cb28485108f6470c979566
	Author: Len Brown <len.brown@intel.com>
	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