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@xxxxxxxxx/
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
