Kyle Marek <kmarek@xxxxxxxx> writes:
> I'll investigate the revision-mark shifting idea. I am concerned that
> it would get complicated if a graph edge extends around a revision
> that needs to be shifted,...
The "current graph layout makes it harder to see where the root is"
problem has a natural solution: fix the graph layout so that the
root is easily visible.
I however think it is a much harder approach to solve than using a
different mark for root commits, and it is the reason why there have
been at least a few attempts in the past that did essentially the
same patch as yours, plus the "linear break" which we accepted.
> * 8d82d0a (HEAD -> master) Merge branch 'o1'
> |\
> | * 3479914 (o1) O1
> | * a674e07 O1 <-- root commit
> | * 2237b52 (t) T
> | * f525fa5 T
> |/
> * f15f936 A
> | * 9e289ed (u) U
> |/
> * ee911c8 initial <-- root commit
>
> vs:
>
> * 8ee9b14 (HEAD -> master) Merge branch 'u'
> |\
> | * ed1990f (u) U
> * | 277f31c Merge branch 'o1'
> |\ \
> | * | eaa71bb (o1) O1
> | * | 9203a43 O1 <-- root commit
> | /
> | | * bc2c4d9 (t) T
> | | * 2d3c03b T
> | |/
> |/|
> * | 6a26183 A
> |/
> * da85ccf initial <-- root commit
Sorry, I am not quite sure what you are trying to illustrate with
the comparison between the above two. The latter makes it clear
that 9203a43 and da85ccf do not have parents in the depicted part of
the history [*1*].
In the former one, does 2237b52 have no child in the depicted part of
the history, and is the problem that it appears as if it has a674e07
as a child? I wonder if we can just shift them, either:
> * 8d82d0a (HEAD -> master) Merge branch 'o1'
> |\__
> | * 3479914 (o1) O1
> | * a674e07 O1 <-- root commit
> | * 2237b52 (t) T
> | * f525fa5 T
> |/
> * f15f936 A
or
> * 8d82d0a (HEAD -> master) Merge branch 'o1'
> |\
> | * 3479914 (o1) O1
> | * a674e07 O1 <-- root commit
> | * 2237b52 (t) T
> | __* f525fa5 T
> |/
> * f15f936 A
Or we could punt to show it with an extra blank line, although it is
suboptimial.
> * 8d82d0a (HEAD -> master) Merge branch 'o1'
> |\
> | * 3479914 (o1) O1
> | * a674e07 O1 <-- root commit
> |
> | * 2237b52 (t) T
> | * f525fa5 T
> |/
> * f15f936 A
[Footnote]
*1* Stepping back a bit, I think concentrating too much on "is it
root?" is a wrong way to think about the problem. Suppose you
have two histories, e.g. (time flows from left to right; A and X
are roots)
A---B
\
X---Y---Z
and doing "git log --graph --oneline Z" would show A, B, X, Y
and Z.
If it benefits to show "A" (and "X") specially in the graph,
that would mean that the current algorithm would show some other
commit after showing A (probably X if it goes in chronological
order), and it probably is confusing because X is shown on the
same column as A, when there is no parent-child relationship
between them (A is root after all).
We are trying to highlight that A is not a child of anybody by
using '#' instead.
But in a slightly modified graph:
C
/
O---A---B
\
X---Y---Z
if you do "git log --graph --oneline C..Z", you should see the
same commits listed as above (A, B, X, Y and Z), and most likely
in the same order.
So special casing by "Ah, A is a root commit, so let's show it
with '#'" does not help, even though we are facing exactly the
same problem in the latter graph.
And the right way to look at it is "does A have any parent in
the part of the history being shown?", not "does A have any
parent?" Then 'A' will get exactly the same treatment in the
two examples, and the visual problem that makes A appear as if
it has parent-child relationship with unrelated commit X goes
away.
