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.com \
--cc=git@vger.kernel.org \
--cc=mst@redhat.com \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.