Re: new file leaked onto release branch

[Junio C Hamano <junkio@cox.net>]

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

> Should I be using something different than git merge?
> is Documentation/howto/using-topic-branches out of date?

I reviewed it once again right now.  The document claims to be
last updated for 0.99.9f, but I do not see anything outdated in
there for the latest.  Tony's procedure looks valid [*1*], so do
the scripts you sent in this thread.

Sorry, but I do not seem to be able to spot anything obviously
wrong with your troubled commits nor scripts.  I'll do some more
digging, including rewinding to an older git and trying them,
but I am pessimistic.

I pointed out one anomaly which is the commit should never have
been created because it was not even a fast forward but already
up-to-date case, and it was followed up with exchange of a few
messages between Linus and you.  But even if we got that mixed
up, the resulting merge should not have contained the file
neither parents had.  That part worries me the most.

One question.  You mentioned these in your message, you have
a "git.commit wrapper" that contains these lines:

    git-update-index --add --remove `quilt files`
    git commit

I am not familiar with 'quilt', but is "quilt files" the command
to show the list of files with patches applied to the working
tree?

If so, the above do tell git about the modified (including added
or removed) files that the applied quilt patches touch, which
sounds like the correct thing to do.

But the resulting commit from that procedure would not be a
merge commit, and the commit in question that had the rsinfo
file magically appeared from nowhere is a merge, so this does
not seem to have much to do with the current problem...

Still puzzlled, sorry.


[Footnote]

*1* Except that the rsync transport is probably suboptimal for
people who stay reasonably up-to-date with Linus and I would
apply the following change if I were Tony, but that shouldn't
have anything to do with the trouble we are discussing here.

---
diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt
index 4698abe..4944297 100644
--- a/Documentation/howto/using-topic-branches.txt
+++ b/Documentation/howto/using-topic-branches.txt
@@ -31,7 +31,7 @@ test tree and then pull to the release t
 patches blocked in the test tree waiting for complex changes to accumulate
 enough test time to graduate.
 
-Back in the BitKeeper days I achieved this my creating small forests of
+Back in the BitKeeper days I achieved this by creating small forests of
 temporary trees, one tree for each logical grouping of patches, and then
 pulling changes from these trees first to the test tree, and then to the
 release tree.  At first I replicated this in GIT, but then I realised
@@ -42,7 +42,8 @@ So here is the step-by-step guide how th
 
 First create your work tree by cloning Linus's public tree:
 
- $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
+ $ git clone \
+   master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
 
 Change directory into the cloned tree you just created
 
@@ -52,7 +53,7 @@ Set up a remotes file so that you can fe
 branch into a local branch named "linus":
 
  $ cat > .git/remotes/linus
- URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+ URL: master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Pull: master:linus
  ^D