"James Coglan via GitGitGadget" [off-list ref] writes:
This effect is applied to both "normal" two-parent merges, and to
octopus merges. It also reduces the vertical space needed for pre-commit
lines, as the merge occupies one less column than usual.
Before: After:
| * | *
| |\ | |\
| | \ | * \
| | \ |/|\ \
| *-. \
| |\ \ \
Looking at these drawings reminded me of a tangent that is brought
up from time to time. We do not do great job when showing multiple
roots.
If you have a history like this:
A---D---E
/
B---C
drawing the graph _with_ the merge gives a reasonable representation
of the entire topology.
* 46f67dd E
* 6f89516 D
|\
| * e6277a9 C
| * 13ae9b2 B
* afee005 A
But if you start drawing from parents of D (excluding D), you'd get
this:
* e6277a9 C
* 13ae9b2 B
* afee005 A
and the fact that B and A do not share parent-child relationships is
lost. An easy way to show that would be to draw the bottom three
lines of the full history output we saw earlier:
| * e6277a9 C
| * 13ae9b2 B
* afee005 A
either with or without the vertical bar to imply that A may have a
child.
This is not something that has to be done as part of this series,
but I am hoping that the internal simplification and code
restructuring that is done by this series would make it easier to
enhance the system to allow such an output.
Thanks.
On 10/16/2019 12:00 AM, Junio C Hamano wrote:
"James Coglan via GitGitGadget" [off-list ref] writes:
quoted
This effect is applied to both "normal" two-parent merges, and to
octopus merges. It also reduces the vertical space needed for pre-commit
lines, as the merge occupies one less column than usual.
Before: After:
| * | *
| |\ | |\
| | \ | * \
| | \ |/|\ \
| *-. \
| |\ \ \
Looking at these drawings reminded me of a tangent that is brought
up from time to time. We do not do great job when showing multiple
roots.
If you have a history like this:
A---D---E
/
B---C
drawing the graph _with_ the merge gives a reasonable representation
of the entire topology.
* 46f67dd E
* 6f89516 D
|\
| * e6277a9 C
| * 13ae9b2 B
* afee005 A
But if you start drawing from parents of D (excluding D), you'd get
this:
* e6277a9 C
* 13ae9b2 B
* afee005 A
I hit this very situation recently when I was experimenting with
'git fast-import' and accidentally created many parallel, independent
histories. Running "git log --graph --all --simplify-by-decoration"
made it look like all the refs were in a line, but they were not.
(The one way I knew something was up: the base commits also appeared
without a decoration. That was the only clue that the histories did
not continue in a line.)
and the fact that B and A do not share parent-child relationships is
lost. An easy way to show that would be to draw the bottom three
lines of the full history output we saw earlier:
| * e6277a9 C
| * 13ae9b2 B
* afee005 A
either with or without the vertical bar to imply that A may have a
child.
The natural extension of this would be multiple columns:
| | | | | *
| | | | *
| | | *
| | *
| *
*
This does not appear too cumbersome, and such a situation should
be rare.
This is not something that has to be done as part of this series,
but I am hoping that the internal simplification and code
restructuring that is done by this series would make it easier to
enhance the system to allow such an output.
I agree. An excellent idea for a follow-up.
Thanks,
-Stolee