Kevin Bracey <ke...@bracey.fi> writes:
> On 06/05/2013 23:36, Junio C Hamano wrote:
>> Kevin Bracey <ke...@bracey.fi> writes:
>>> +# ,---E--. *H----------. * marks !TREESAME parent
>>> +# / \ / \*
>>> +# *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
>> 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
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.
> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html