git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	git@vger.kernel.org, sunshine@sunshineco.com, peff@peff.net
Subject: Re: [PATCH v5 5/9] patch-id: document new behaviour
Date: Sun, 27 Apr 2014 21:26:23 +0300	[thread overview]
Message-ID: <20140427182623.GA28551@redhat.com> (raw)
In-Reply-To: <xmqqzjjatm0x.fsf@gitster.dls.corp.google.com>

On Thu, Apr 24, 2014 at 03:12:14PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> >> > +--unstable::
> >> > +	Use a non-symmetrical sum of hashes, such that reordering
> >> 
> >> What is a non-symmetrical sum?
> >
> > Non-symmetrical combination function is better?
> 
> I do not think either is very good X-<.
> 
> The primary points to convey for "--stable" are:
> 
>  - Two patches produced by comparing the same two trees with two
>    different settings for "-O<orderfile>" will result in the same
>    patchc signature, thereby allowing the computed result to be used
>    as a key to index some metainformation about the change between
>    the two trees;
> 
>  - It will produce a result different from the plain vanilla
>    patch-id has always produced even when used on a diff output
>    taken without any use of "-O<orderfile>", thereby making existing
>    databases keyed by patch-ids unusable.
> 
> The fact that we happened to use a patch-id that catches that
> somebody reordered the same patch into different file order and
> declares that they are two different changes is a more historical
> accident than a designed goal.
> 
> I would even say that we would have used the "stable" version from
> the beginning if we thought that "-O<orderfile>" would be widely
> used when these two features both appeared.  Even though I was the
> guilty one who introduced it, I'd admit that "-O<orderfile>" has
> merely been a curiosity from its inception and has been a failed
> experiment, not in the sense that the feature does not work as
> adverertised (it does), but in the sense that it is not widely used
> (evidenced by the lack of complaints on missing diff.orderfile for a
> long time) at all.  With "-O<orderfile>" being a failed experiment,
> the "unstability" did not matter, so it has stuck.
> 
> The only two things worth mentioning about "--unstable", if our
> future direction is to see diff.orderfile and "--stable" a lot more
> widely used, are:
> 
>  (1) it keeps producing the same patch-id as existing versions of
>      Git, so users with existing databases (who do not deal with
>      reordered patches) may want to use it; and perhaps
> 
>  (2) it will not consider a patch taken with "-O<orderfile>" and
>      another without it from the same source the same patches.
> 
> Mathmatically speaking, mentioning "non-symmetrial" might be one way
> of expressing the latter point (2), but stressing on that alone
> without mentioning (1) misses the point.  (2) is _not_ a designed
> feature, so it is not very interesting.  Unless you have an existing
> database, there is no reason to use "--unstable".
> 
> On the other hand (1) is a very relevant thing to mention, as we are
> talking about a feature that, if unused, may break existing users'
> data.

OK I did just that, pls take a look.

  reply	other threads:[~2014-04-27 18:25 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
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 [this message]
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=20140427182623.GA28551@redhat.com \
    --to=mst@redhat.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.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).