Re: Interesting git-format-patch bug

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 26, 2012, 22:56 UTC
Message-ID: <7vobikotwd.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4B2793BF110AAB47AB0EE7B9089703854CA7BA61@fmsmsx110.amr.corp.intel.com>

"Olsen, Alan R" <alan.r.olsen@intel.com> writes:

Show 12 quoted lines

> 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".

I think you could make your "some other process" that rewrites commits to cull the duplicates out of the format-patch output, though. Each output file identifies what commit object the patch came from, and your "some other process" that rewrote the commits ought to know which commit updated which other commit did, which is the piece of information needed to remove duplicates that format-patch does not have.