git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: git@vger.kernel.org, sunshine@sunshineco.com, peff@peff.net,
	gitster@pobox.com
Subject: Re: [PATCH v5 4/9] patch-id: make it stable against hunk reordering
Date: Thu, 24 Apr 2014 10:30:44 -0700	[thread overview]
Message-ID: <20140424173043.GJ15516@google.com> (raw)
In-Reply-To: <1398331809-11309-4-git-send-email-mst@redhat.com>

Hi,

Michael S. Tsirkin wrote:

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

Hm.

If the goal is that functionally equivalent patches are guaranteed to
produce the same patch-id, I wonder if we should be doing something
like the following:

 1. apply the patch in memory
 2. generate a new diff
 3. use that new diff to produce a patch-id

Otherwise issues like --diff-algorithm=patience versus =myers will
create trouble too.  I don't think that avoiding false negatives for
patch comparison without doing something like that is really possible.

On the other hand if someone reorders file diffs within a patch, that
is a potentially very common thing to do and something worth fixing.
In other words, while your (1) makes perfect sense to me, case (2)
seems less convincing.

The downside of allowing reordering hunks is that it can potentially
make different patches to be treated the same (for example if they
were making similar changes to different functions) when the ordering
previously caused them to be distinguished.  But that wasn't something
people could count on anyway, so I don't mind.

Should the internal patch-id computation used by commands like 'git
cherry' (see diff.c::diff_get_patch_id) get the same change?  (Not a
rhetorical question --- I don't know what the right choice would be
there.)

[...]
> The new behaviour is enabled
> - when patchid.stable is true
> - when --stable flag is present
>
> Using a new flag --unstable or setting patchid.stable to false force
> the historical behaviour.

Which is the default?

[...]
>  builtin/patch-id.c | 89 ++++++++++++++++++++++++++++++++++++++++++++----------
>  1 file changed, 73 insertions(+), 16 deletions(-)

Documentation?  Tests?

Thanks,
Jonathan

  reply	other threads:[~2014-04-24 17:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-24  9:30 [PATCH v5 1/9] diff: add a config option to control orderfile Michael S. Tsirkin
2014-04-24  9:30 ` [PATCH v5 2/9] test: add test_write_lines helper Michael S. Tsirkin
2014-04-24 17:08   ` Jonathan Nieder
2014-04-24 18:31     ` Junio C Hamano
2014-04-24  9:30 ` [PATCH v5 3/9] tests: new test for orderfile options Michael S. Tsirkin
2014-04-24 17:11   ` Jonathan Nieder
2014-04-24 18:45   ` Junio C Hamano
2014-04-24 21:39     ` Michael S. Tsirkin
2014-04-24  9:31 ` [PATCH v5 4/9] patch-id: make it stable against hunk reordering Michael S. Tsirkin
2014-04-24 17:30   ` Jonathan Nieder [this message]
2014-04-24 19:12     ` Junio C Hamano
2014-04-24 21:32     ` Michael S. Tsirkin
2014-04-24  9:31 ` [PATCH v5 5/9] patch-id: document new behaviour Michael S. Tsirkin
2014-04-24 17:33   ` Jonathan Nieder
2014-04-24 21:26     ` Michael S. Tsirkin
2014-04-24 22:12       ` Junio C Hamano
2014-04-27 18:26         ` Michael S. Tsirkin
2014-04-24  9:31 ` [PATCH v5 6/9] patch-id-test: test stable and unstable behaviour Michael S. Tsirkin
2014-04-24  9:31 ` [PATCH v5 7/9] patch-id: change default to stable Michael S. Tsirkin
2014-04-24  9:31 ` [PATCH v5 8/9] t4204-patch-id.sh: default is now stable Michael S. Tsirkin
2014-04-24  9:31 ` [PATCH v5 9/9] Documentation/git-patch-id.txt: default is stable Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140424173043.GJ15516@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mst@redhat.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).