From: Junio C Hamano <gitster@pobox•com>
To: "Michael S. Tsirkin" <mst@redhat•com>
Cc: Jacob Keller <jacob.keller@gmail•com>, Jeff King <peff@peff•net>,
Stefan Beller <sbeller@google•com>,
"git\@vger.kernel.org" <git@vger•kernel.org>,
Jacob Keller <jacob.e.keller@intel•com>
Subject: Re: [PATCH 2/2] xdiff: implement empty line chunk heuristic
Date: Wed, 20 Apr 2016 09:09:53 -0700 [thread overview]
Message-ID: <xmqqpotkw9bi.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160420161028-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Wed, 20 Apr 2016 16:12:08 +0300")
"Michael S. Tsirkin" <mst@redhat•com> writes:
> FWIW IIRC what that commit is about is ability to reorder the chunks in
> a patch without changing patch-id. Not about keeping id stable across
> git revisions.
OK, but "reorder the chunks" is not meant to stay to be the _ONLY_
purpose for an option whose name is a broad "--[un]stable", but
merely one (and only) possible cause of patch-id instability that
happened to be noticed as an issue back then and was dealt with that
commit, no? In other words, the intent of the "--stable" feature is
to give a stable ID that is not affected by random end-user settings
(e.g. diff.orderfile) and if somebody invents a new configurable knob
in the future, they are supposed to pay attention to the "--stable"
feature or existing users who do use "--stable" will be broken, no?
I can still buy "--stable is not about stability across versions of
Git"--it makes our job easier ;-) I just want to make sure that
"--stable is about stability inside a single version of Git that
patch ID for the same commit will stay the same and unaffected by
random end-user configuration knobs".
Which in turn would mean that we won't have to worry about this
option in patch-id as long as we remove the diff.compactionheuristic
configuration and command line option once the developers are done
experimenting with their heuristics code.
next prev parent reply other threads:[~2016-04-20 16:10 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 21:12 [PATCH 0/2 v4] xdiff: implement empty line chunk heuristic Stefan Beller
2016-04-18 21:12 ` [PATCH 1/2] xdiff: add recs_match helper function Stefan Beller
2016-04-18 21:12 ` [PATCH 2/2] xdiff: implement empty line chunk heuristic Stefan Beller
2016-04-18 22:04 ` Jacob Keller
2016-04-18 22:24 ` Junio C Hamano
2016-04-19 5:03 ` Jeff King
2016-04-19 6:47 ` Stefan Beller
2016-04-19 7:00 ` Jeff King
2016-04-19 7:05 ` Stefan Beller
2016-04-19 15:17 ` Stefan Beller
2016-04-19 17:06 ` Jeff King
2016-04-19 23:02 ` Jacob Keller
2016-04-19 23:07 ` Junio C Hamano
2016-04-20 13:12 ` Michael S. Tsirkin
2016-04-20 16:09 ` Junio C Hamano [this message]
2016-04-20 16:17 ` Jeff King
2016-04-20 6:00 ` Junio C Hamano
2016-04-19 16:51 ` Junio C Hamano
2016-04-18 21:22 ` [PATCH 0/2 v4] " Junio C Hamano
2016-04-18 23:53 ` Stefan Beller
-- strict thread matches above, loose matches on Subject: below --
2016-04-19 15:21 [PATCHv5 0/2] " Stefan Beller
2016-04-19 15:21 ` [PATCH 2/2] " Stefan Beller
[not found] ` <CA+P7+xoqn3fxEZGn02ST1XV-2UpQGr3iwV-37R8pakFJy_9n0w@mail.gmail.com>
2016-04-20 4:18 ` Jeff King
2016-04-20 4:37 ` Jeff King
2016-04-20 4:37 ` Stefan Beller
2016-04-29 20:29 ` Junio C Hamano
2016-04-29 20:59 ` Jacob Keller
2016-04-29 22:18 ` Junio C Hamano
2016-04-29 22:35 ` Stefan Beller
2016-04-29 22:39 ` Keller, Jacob E
2016-04-29 22:44 ` Stefan Beller
2016-04-29 22:48 ` Keller, Jacob E
2016-05-02 17:40 ` Junio C Hamano
2016-05-02 17:45 ` Stefan Beller
2016-05-02 18:02 ` Jeff King
2016-05-03 17:55 ` Jacob Keller
2016-04-30 3:06 ` Jeff King
2016-04-15 23:01 [RFC PATCH, WAS: "weird diff output?" v3a 0/2] implement shortest line diff " Stefan Beller
2016-04-15 23:01 ` [PATCH 2/2] xdiff: implement empty line " Stefan Beller
2016-04-15 23:05 ` Jacob Keller
2016-04-15 23:32 ` Jacob Keller
2016-04-15 23:45 ` Stefan Beller
2016-04-16 0:49 ` Junio C Hamano
2016-04-16 0:59 ` Stefan Beller
2016-04-16 1:07 ` Jacob Keller
2016-04-18 19:22 ` Junio C Hamano
2016-04-18 19:33 ` Stefan Beller
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=xmqqpotkw9bi.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jacob.e.keller@intel$(echo .)com \
--cc=jacob.keller@gmail$(echo .)com \
--cc=mst@redhat$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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