Re: [PATCH v3 3/9] t6111: new TREESAME test set

[Junio C Hamano <gitster@pobox.com>]

Kevin Bracey <kevin@bracey.fi> writes:

> On 06/05/2013 23:36, Junio C Hamano wrote:
>> Kevin Bracey <kevin@bracey.fi> writes:
>>
>>> +#        ,---E--.   *H----------.             * marks !TREESAME parent paths
>>> +#       /        \ /             \*
>>> +# *A--*B---D--*F-*G---------K-*L-*M
>>> +#   \     /*       \       /
>>> +#    `-C-'          `-*I-*J
>>> +#
>>> +# A creates "file", B and F change it.
>>> +# Odd merge G takes the old version from B.
>>> +# I changes it, but J reverts it.
>>> +# H and L both change it, and M merges those changes.
>>> + ...
> ...
>>> +check_outcome failure 'M L H' G..M -- file # includes J I
>>> +check_outcome failure 'M L H' G..M --parents -- file # includes J I
>> I am not sure if it should be a failure or your expectation is wrong.
>> G is outside the graph, so as far as the remainder of the graph is concerned,
>> J is the sole remaining parent of K and I and J did change the path in question.
>>
>> What makes you think I and J should be excluded in these cases?
>
> Because it's the simplest answer to the question "what happened in
> M since G", which is what "G..M" is supposed to mean. ...
> 
> This all comes about because the formal graph definition doesn't
> match the user interface. The question "B..C" currently generates
> a graph of all commits in C since B, and the connections between
> those commits. It turns out to be problematic that the graph
> doesn't include the connection to B itself. It would be fine if
> only worrying about nodes in the graph. But it's not fine when you
> start doing graph operations that care about edge connections to
> parents.

OK, that makes sense.

> ...
> What I'm effectively doing is extending the graph to actually
> include the unshown bottom. I think it just makes more sense.

Yup, and this is a good summary.


> ... I assume you mean:
>
>> That is, "-a-p F..M" makes F the sole remaining parent of G and G does change the
>> path from F so it should be shown, while "-a-p E..M" makes E the sole parent of G,
>> and G does not change the path from E, so it should not be shown.

Yes.

> Which is the way the logic works - we treat F and E as
> interesting/priority parents when they're specified as a bottom in
> each case. Without doing that, G would have 2 differing and
> equally (un)important parents in each case, and thus would be
> shown in both cases.
>
> In this case, the same logic says that G is treated as an
> interesting parent of K because it is the specified bottom. Which
> then enables the default following to follow that path direct to
> G, rather than having to go down the IJ path (which leads to G
> anyway).

OK.