"Jason Pyeron" [off-list ref] writes:
One and the same issue. Placing an * directly above another * is the issue.
OK, I re-read the messages in the thread, and it appears that this
part from Kyle
quoted
quoted
C
/
O---A---B
\
X---Y---Z
When graphing C..Z, git produces output like:
* 0fbb0dc (HEAD -> z) Z
|\
| * 11be529 (master) B
| * 8dd1b85 A
* 851a915 Y
* 27d3ed0 (x) X
We cannot tell from the above graph alone that X is a root and A is not.
was the only thing that argued that A and X (if the graph drawing
happend to place an unrelated commit immediately below it) should be
drawn differently so that you can tell X (root) and A (non root)
apart.
And you are saying (and it seems that you have consistently been
saying) that it is OK to draw A and X (again if other unrelated
commits were immediately drawn below them) the same way. So I guess
all is well. We do not have to use more 6 different symbols ("{#}"
to show commit above boundary, three more to show roots) but need to
introduce only three, if we were to go with the Solution #1 route.
It seems to me that Solution #2 is a special case of Solution #3 ;-)
They are both direct answers to the "graph drawn incorrectly can
imply ancestry that does not exist" problem.
Adding the "--decorate-roots" option that annotates the root commits
in the "git log" output can still be done, but that is an orthogonal
issue. It does solve, together with any one of three options you
presented, the issue Kyle brought up, I would think.
Thanks.
From: Junio C Hamano
Sent: Saturday, January 23, 2021 6:45 PM
"Jason Pyeron" writes:
quoted
One and the same issue. Placing an * directly above another * is the issue.
OK, I re-read the messages in the thread, and it appears that this
part from Kyle
Added more of the context below.
quoted
quoted
quoted
While root commits are not a special case in the sense that --graph
makes ancestor implications for more than just root commits, root
commits are a special case when we think about interpreting the presence
of hidden lineage in --graph output.
Considering one of your examples:
C
/
O---A---B
\
X---Y---Z
When graphing C..Z, git produces output like:
* 0fbb0dc (HEAD -> z) Z
|\
| * 11be529 (master) B
| * 8dd1b85 A
* 851a915 Y
* 27d3ed0 (x) X
We cannot tell from the above graph alone that X is a root and A is not.
This was a side track down the left right issue. I personally feel that using the left right features is a buyer beware situation.
was the only thing that argued that A and X (if the graph drawing
happend to place an unrelated commit immediately below it) should be
drawn differently so that you can tell X (root) and A (non root)
apart.
And you are saying (and it seems that you have consistently been
saying) that it is OK to draw A and X (again if other unrelated
I am neither saying or not saying that - partial graph issues are outside of my concerns. Kyle was attempting to reconcile comments on this list about partial graph rendering when his patch was submitted.
commits were immediately drawn below them) the same way. So I guess
all is well. We do not have to use more 6 different symbols ("{#}"
to show commit above boundary, three more to show roots) but need to
introduce only three, if we were to go with the Solution #1 route.
Honestly, I do not care about the <>{}. Whatever makes sense.
It seems to me that Solution #2 is a special case of Solution #3 ;-)
They are both direct answers to the "graph drawn incorrectly can
imply ancestry that does not exist" problem.
Adding the "--decorate-roots" option that annotates the root commits
in the "git log" output can still be done, but that is an orthogonal
issue. It does solve, together with any one of three options you
presented, the issue Kyle brought up, I would think.
Yes, adding --decorate-roots to add more wide descriptive text before the message would do it, but it is the worst solution #4.
Thanks.
"Jason Pyeron" [off-list ref] writes:
quoted
It seems to me that Solution #2 is a special case of Solution #3 ;-)
They are both direct answers to the "graph drawn incorrectly can
imply ancestry that does not exist" problem.
Adding the "--decorate-roots" option that annotates the root commits
in the "git log" output can still be done, but that is an orthogonal
issue. It does solve, together with any one of three options you
presented, the issue Kyle brought up, I would think.
Yes, adding --decorate-roots to add more wide descriptive text
before the message would do it, but it is the worst solution #4.
I said that "--decorate-roots" is a solution to an orthogonal issue.
Let's recall the C..Z example that shows A (non-root) and X (root)
in several messages back. Either can be drawn with unrelated commit
immediately below them, depending on the topology of other commits
(imagine there is another commit M that is not related to any of the
commits connected to A or Z, and it is given to "git log C..Z M"; if
we draw C..Z part first and then draw O after it, M would most
likely come immediately after X.
(history: time flows left to right)
C
/
O---A---B
\
X---Y---Z
M
(log --graph output: time flows bottom to top)
* 0fbb0dc (HEAD -> z) Z
|\
| * 11be529 (master) B
| * 8dd1b85 A
* 851a915 Y
* 27d3ed0 [root] X
* 1111111 M
Now, the earlier C..Z example I happened to draw B and A first
before drawing Y and X, but if we swap the merge order of Z, it is
likely that the graph output would draw Y and X and then B and A.
"git log C..Z M" in such a history would likely to show M directly
below A (non-root).
* 0fbb0dc (HEAD -> z) Z
|\
| * 851a915 Y
| * 27d3ed0 [root] X
* 11be529 (master) B
* 8dd1b85 A
* 1111111 M
In short, the [root] annotation does not, and it is not meant to,
solve the "misleading graph" issue.
It only solves "root is special, with or without --graph" issue
(such an issue may or may not exist).