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