From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: "Michael S. Tsirkin" <mst@redhat•com>, git@vger•kernel.org
Subject: Re: [PATCH] diff: add a config option to control orderfile
Date: Tue, 17 Sep 2013 14:52:45 -0700 [thread overview]
Message-ID: <xmqqob7rw1xt.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20130917205615.GA20178@sigill.intra.peff.net> (Jeff King's message of "Tue, 17 Sep 2013 16:56:16 -0400")
Jeff King <peff@peff•net> writes:
> 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.
It does not. The reason rerere is relevant in that thread but is
not directly relevant here is because the thread is about changing
the diff algorithm, hence changing the common-sequence matches
between preimage and postimage, resulting in a different shape of
the conflicted section. The hash rerere does still depends on the
patch text, but it is restricted to the conflicted region, so
whatever we do in patch-id will not affect it. Also the rerere
database is not keyed by pathname (a conflict in _any_ file as long
as they have the same ours/theirs conflicted text is recognised as
the same conflict we have already seen), so changing the orderfile
would not affect it at all.
next prev parent reply other threads:[~2013-09-17 21:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-31 19:44 [PATCH] diff: add a config option to control orderfile Michael S. Tsirkin
2013-09-03 17:12 ` Junio C Hamano
2013-09-03 21:08 ` Michael S. Tsirkin
2013-09-15 7:49 ` Michael S. Tsirkin
2013-09-15 8:08 ` Michael S. Tsirkin
2013-09-17 16:26 ` Junio C Hamano
2013-09-17 16:42 ` Michael S. Tsirkin
2013-09-17 17:24 ` Junio C Hamano
2013-09-17 17:28 ` Michael S. Tsirkin
2013-09-17 18:06 ` Junio C Hamano
2013-09-17 19:25 ` Michael S. Tsirkin
2013-09-17 20:14 ` Michael S. Tsirkin
2013-09-17 20:16 ` Michael S. Tsirkin
2013-09-17 20:18 ` Jeff King
2013-09-17 20:38 ` Michael S. Tsirkin
2013-09-17 20:41 ` Michael S. Tsirkin
2013-09-17 20:56 ` Jeff King
2013-09-17 21:03 ` Michael S. Tsirkin
2013-09-17 21:06 ` Jeff King
2013-09-17 21:52 ` Junio C Hamano [this message]
2013-09-19 21:32 ` Michael S. Tsirkin
2013-09-23 21:09 ` Michael S. Tsirkin
2013-09-23 21:37 ` Jonathan Nieder
2013-09-24 5:45 ` Jeff King
2013-09-24 5:54 ` Michael S. Tsirkin
2013-09-24 19:36 ` Jonathan Nieder
2013-09-24 20:15 ` Michael S. Tsirkin
2013-09-24 21:31 ` Jonathan Nieder
2013-09-24 21:57 ` Michael S. Tsirkin
2013-09-24 22:08 ` Jonathan Nieder
2013-09-17 20:31 ` Michael S. Tsirkin
2013-09-21 21:08 ` 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=xmqqob7rw1xt.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mst@redhat$(echo .)com \
--cc=peff@peff$(echo .)net \
/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