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

Kevin Bracey [off-list ref] writes:

On 06/05/2013 23:36, Junio C Hamano wrote:

quoted

Kevin Bracey [off-list ref] writes:

quoted

+#        ,---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.
+ ...

...

quoted

quoted

+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:

quoted

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.