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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html