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 >>> 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. -- 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
