From: Kevin Bracey <kevin@bracey.fi>
To: "Jeff King" <peff@peff.net>, "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Git mailing list <git@vger.kernel.org>
Subject: Re: Weird revision walk behaviour
Date: Thu, 24 May 2018 23:26:24 +0300 [thread overview]
Message-ID: <869a4045-0527-3dcf-33b3-90de2a45cd51@bracey.fi> (raw)
In-Reply-To: <20180523173523.GB10299@sigill.intra.peff.net>
On 23/05/2018 20:35, Jeff King wrote:
> On Wed, May 23, 2018 at 01:32:46PM -0400, Jeff King wrote:
>
>> On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote:
>>
>>> $ git log --oneline master..ba95710a3b -- ci/
>>> ea44c0a594 Merge branch 'bw/protocol-v2' into jt/partial-clone-proto-v2
>>>
>>>
>>> I keep some older builds around, and it does not reproduce with v1.6.6.3
>>> (that's my usual goto for "old"). Bisecting turns up d0af663e42
>>> (revision.c: Make --full-history consider more merges, 2013-05-16). It
>>> looks like an unintended change (the commit message claims that the
>>> non-full-history case shouldn't be affected).
> There's more discussion in the thread at:
>
> https://public-inbox.org/git/1366658602-12254-1-git-send-email-kevin@bracey.fi/
>
> I haven't absorbed it all yet, but I'm adding Junio to the cc.
>
In this case, we're hitting a merge commit which is not on master, but
it has two parents which both are. Which, IIRC, means the merge commit
is INTERESTING with two UNINTERESTING parents; and we are TREESAME to
only one of them.
The commit changing the logic of TREESAME you identified believes that
those TREESAME changes for merges which were intended to improve fuller
history modes shouldn't affect the simple history "because partially
TREESAME merges are turned into normal commits". Clearly that didn't
happen here.
I think we need to look at why that isn't happening, and if it can be
made to happen. The problem is that this commit is effectively the base
of the graph - it's got a double-connection to the UNINTERESTING set,
and maybe that prevented the simple history "follow 1 TREESAME" logic
from kicking in. Maybe it won't follow 1 TREESAME to UNINTERESTING.
I know there were quite a few changes later in the series to try to
reconcile the simple and full history, for the cases where the simple
history takes a weird path because of its love of TREESAME parents,
hiding evil merges. But I believe the simple history behaviour was
supposed to remain as-is - take first TREESAME always.
Kevin
next prev parent reply other threads:[~2018-05-24 21:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 17:10 Weird revision walk behaviour SZEDER Gábor
2018-05-23 17:32 ` Jeff King
2018-05-23 17:35 ` Jeff King
2018-05-24 18:54 ` Kevin Bracey
2018-05-24 20:26 ` Kevin Bracey [this message]
2018-05-27 17:37 ` Kevin Bracey
2018-05-28 22:06 ` SZEDER Gábor
2018-05-29 6:11 ` Kevin Bracey
2018-05-29 21:04 ` Jeff King
2018-05-30 8:20 ` Kevin Bracey
2018-05-31 5:43 ` Jeff King
2018-05-31 14:54 ` Kevin Bracey
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=869a4045-0527-3dcf-33b3-90de2a45cd51@bracey.fi \
--to=kevin@bracey.fi \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=szeder.dev@gmail.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 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.