Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Olsen\, Alan R" <alan.r.olsen@intel.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Interesting git-format-patch bug
Date: Mon, 26 Nov 2012 14:56:34 -0800	[thread overview]
Message-ID: <7vobikotwd.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4B2793BF110AAB47AB0EE7B9089703854CA7BA61@fmsmsx110.amr.corp.intel.com> (Alan R. Olsen's message of "Mon, 26 Nov 2012 21:33:01 +0000")

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

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

  reply	other threads:[~2012-11-26 22:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-26 21:33 Interesting git-format-patch bug Olsen, Alan R
2012-11-26 22:56 ` Junio C Hamano [this message]
2012-11-27  4:15   ` Perry Hutchison
2012-11-27 17:29     ` Junio C Hamano
2012-11-27 20:31     ` Olsen, Alan R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vobikotwd.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=alan.r.olsen@intel.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox