new file leaked onto release branch

[Len Brown <len.brown@intel.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