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