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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Sep 17, 2013 at 04:56:16PM -0400, Jeff King wrote:
> On Tue, Sep 17, 2013 at 11:38:07PM +0300, Michael S. Tsirkin wrote:
> 
> > > 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.

We can always do a compatibility option. --order-sensitive ?
--ignore-order ?

> 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

I think so too.