On Mon, Mar 31, 2014 at 10:59:50AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
Patch id changes if users
1. reorder file diffs that make up a patch
or
2. split a patch up to multiple diffs that touch the same path
(keeping hunks within a single diff ordered to make patch valid).
As the result is functionally equivalent, a different patch id is
surprising to many users.
In particular, reordering files using diff -O is helpful to make patches
more readable (e.g. API header diff before implementation diff).
Change patch-id behaviour making it stable against these two kinds
of patch change:
1. calculate SHA1 hash for each hunk separately and sum all hashes
(using a symmetrical sum) to get patch id
2. hash the file-level headers together with each hunk (not just the
first hunk)
We use a 20byte sum and not xor - since xor would give 0 output
for patches that have two identical diffs, which isn't all that
unlikely (e.g. append the same line in two places).
Add a new flag --unstable to get the historical behaviour.
Add --stable which is a nop, for symmetry.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
changes from v2:
several bugfixes
changes from v1:
hanges from v1: documented motivation for supporting
diff splitting (and not just file reordering).
No code changes.
builtin/patch-id.c | 72
++
1 file changed, 56 insertions(+), 16 deletions(-)
Does this have to interact or be consistent with patch-ids.c which
is the real patch-id machinery used to filter like-changes out by
cherry-pick and log --cherry-pick?
I don't know off-hand.
Specifically, this is diff_flush_patch_id and in diff.c, isn't it?
This series opens a very interesting opportunity by making it
possible to introduce the equivalence between two patches that touch
the same file and a single patch that concatenates hunks from these
two patches.
One example I am wondering about is perhaps this could be used to
detect two branches, both sides with many patches cherry-picked from
the same source, but some patches squashed together on one branch
but not on the other. It would be very nice if you can detect that
two sets of patches are equivalent taken as a whole in such a
situation while rebasing one on top of the other.
Another example is that another mode that gives a set of broken-up
patch-ids for each hunk contained in the input. Suppose there is a
patch that is only meant to be used on the proprietary fork of an
open source project, and the project releases the open source
portion by cherry-picking topics from the development tree used for
the proprietary trunk. The integration service of such a project
used to prepare the open source branch may want to have a
pre-receive hook that says do not merge any commit to cause this
this hunk appear in the result, no matter what other changes the
patches in the commit may bring in, and broken-down patch-ids
(e.g. diff HEAD...$commit | patch-id --individual) may be an
ingredient to implement such a hook. There may be interesting
applications other than such a broken-down patch-ids that can be
based on the enhancement you are presenting here.
OK sure, I can tweak that to use the same algorithm if desired,
though it does look like an unrelated enhancement to me.
Agree?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
