Re: [PATCH] diff: add a config option to control orderfile

From: Jeff King <peff@peff.net>
Date: Sep 17, 2013, 20:56 UTC
Message-ID: <20130917205615.GA20178@sigill.intra.peff.net>
In-Reply-To: <20130917203807.GA22059@redhat.com>

On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:

Show 5 quoted lines

> > A problem with both schemes, though, is that they are not
> > backwards-compatible with existing git-patch-id implementations.
> 
> Could you clarify?
> We never send patch IDs on the wire - how isn't this compatible?

I meant that you might be comparing patch-ids generated by different implementations, or across time. There are no dedicated tools to do so, but it is very easy to do so with standard tools like "join".

For example, you can do:

  patch_ids() {
    git rev-list "$1" |
    git diff-tree --stdin -p |
    git patch-id |
    sort
  }

  patch_ids origin..topic1 >us
  patch_ids origin..topic2 >them

  join us them | cut -d' ' -f2-3

to get a list of correlated commits between two branches. If the "them" was on another machine with a different implementation (or is saved from an earlier time), your patch-ids would not match.

It may be esoteric enough not to worry about, though. By far the most common use of patch-ids is going to be in a single "rev-list --cherry-pick" situation where you are trying to omit commits during a rebase.

I am mostly thinking of the problems we had with the "kup" tool, which expected stability across diffs that would be signed by both kernel.org. But as far as I know, they do not use patch-id. More details in case you are curious (including me arguing that we should not care, and it is kup's problem!) are here:

  http://thread.gmane.org/gmane.comp.version-control.git/192331/focus=192424

rerere is mentioned in that thread, but I believe that it does its own hash, and does not rely on patch-id.

-Peff