Re: Interesting git-format-patch bug

perryh@pluto.rain.com (Perry Hutchison) writes:

Junio C Hamano [off-list ref] wrote:

quoted

"Olsen, Alan R" [off-list ref] writes:

quoted

I found an interesting bug in git-format-patch.

Say you have a branch A.  You create branch B and add a patch to
it. You then merge that patch into branch A. After the merge,
some other process (we will call it 'gerrit') uses annotate and
changes the comment on the patch that exists on branch B.

Now someone runs git-format-patch for the last n patches on
branch A.  You should just get the original patch that was
merged over to branch A.  What you get is the patch that was
merged to branch A *and* the patch with the modified commit
comment on branch B. (Double the patches, double the
clean-up...)

As you literally have patches that do essentially the same or
similar things on two branches that was merged, you cannot
expect to export each individual commit into a patch and not
have conflicts among them.  So I do not think there is no
answer than "don't do that".

To me, this seems to miss Alan's point:  only one patch was merged
to branch A,...

Are you sure about this part?

I thought Alan's description was that he originally had this

    x-----A
     \     \
      B-----M (a)

and then "some other process" made it like so:

    x-----A
    |\     \
    | B-----M
     \       \
      B'------M' (a)

and then you ask to linealize the last n patches starting from the
rewritten M'.

If that "some other process" instead created a history like this:

    x-----A---\
    |\     \   \ 
    | B-----M   \
     \           \
      B'----------M' (a)

then the redone-merge M' will not see the old B that was fixed later
to B' in the history, but then format-patch would not show B so we
wouldn't be having this discussion thread.

It is possible that "some other process" may (ab)use the parent
field to record the evolution of B, to create a topology like this:

    x-----A---\
    |\     \   \
    | B-----M   \
     \ \         \
      \-B'--------M' (a)

in which case M' has parent B' but B' has a (phoney) parent B.

So again, it all depends on what "some other process" does to the
history when it rewrites it, and if somebody wants to fiter cruft in
the resulting history when flattening it, the knowledge of what
"some other process" does need to help that process.

Which is what I already said, I guess ;-)

so git-format-patch applied to branch A should find
only one patch.  It can be argued either way whether that one-patch
report should include the gerrit annotations, but surely the
application of gerrit on branch B, _after the merge to branch A
has already been performed_, should not cause an additional patch
to magically appear on branch A.