# [PATCH] graph.c: visual difference on subsequent series 7 messages from 2014-11-10 to 2015-09-04. Participants: Antoine Beaupré, Junio C Hamano, Michael J Gruber. Thread: https://gitlist.dev/t/37925 ## Antoine Beaupré, 2014-11-10 13:33 Subject: [PATCH] graph.c: visual difference on subsequent series Message-ID: <1415626412-573-1-git-send-email-anarcat@koumbit.org> URL: https://gitlist.dev/e/1415626412-573-1-git-send-email-anarcat%40koumbit.org ``` For projects with separate history lines and, thus, multiple root-commits, the linear arrangement of `git log --graph --oneline` does not allow the user to spot where the sequence ends, giving the impression that it's a contiguous history. E.g. History sequence A: a1 -- a2 -- a3 (root-commit) History sequence B: b1 -- b2 -- b3 (root-commit) git log --graph --oneline * a1 * a2 * a3 * b1 * b2 * b3 In a GUI tool, the root-commit of each series would stand out on the graph. This modification changes the commit char to a different symbol ('o'), so users of the command-line graph tool can easily identify root-commits and make sense of where each series is limited to. git log --graph --oneline * a1 * a2 o a3 * b1 * b2 o b3 The 'o' character was chosen because it is the same character used in rev-list to mark root commits. This patch is similar than the one provided by Milton Soares Filho in 1382734287.31768.1.git.send.email.milton.soares.filho@gmail.com but was implemented independently and uses the 'o' character instead of 'x'. Other solutions were discarded for those reasons: * line delimiters: we want to keep one commit per line * tree indentation: it makes little sense with commit trees without common history, and is more complicated to implement Signed-off-by: Antoine Beaupré --- revision.c | 8 ++++++-- t/t4202-log.sh | 10 +++++----- t/t6016-rev-list-graph-simplify-history.sh | 14 +++++++------- 3 files changed, 18 insertions(+), 14 deletions(-) diff --git a/revision.c b/revision.c index 75dda92..5f21e24 100644 --- a/revision.c +++ b/revision.c @@ -3246,8 +3246,12 @@ char *get_revision_mark(const struct rev_info *revs, const struct commit *commit return "<"; else return ">"; - } else if (revs->graph) - return "*"; + } else if (revs->graph) { + if (commit->parents) + return "*"; + else + return "o"; + } else if (revs->cherry_mark) return "+"; return ""; diff --git a/t/t4202-log.sh b/t/t4202-log.sh index 99ab7ca..d11876e 100755 --- a/t/t4202-log.sh +++ b/t/t4202-log.sh @@ -244,7 +244,7 @@ cat > expect < expect <<\EOF |/ * third * second -* initial +o initial EOF test_expect_success 'log --graph with merge' ' @@ -338,7 +338,7 @@ cat > expect <<\EOF | | second | -* commit tags/side-1~3 +o commit tags/side-1~3 Author: A U Thor initial @@ -410,7 +410,7 @@ cat > expect <<\EOF * | third |/ * second -* initial +o initial EOF test_expect_success 'log --graph with merge' ' @@ -799,7 +799,7 @@ cat >expect <<\EOF | -one | +ichi | -* commit COMMIT_OBJECT_NAME +o commit COMMIT_OBJECT_NAME Author: A U Thor initial diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh index f7181d1..74b6fc3 100755 --- a/t/t6016-rev-list-graph-simplify-history.sh +++ b/t/t6016-rev-list-graph-simplify-history.sh @@ -81,7 +81,7 @@ test_expect_success '--graph --all' ' echo "|/| " >> expected && echo "* | $A2" >> expected && echo "|/ " >> expected && - echo "* $A1" >> expected && + echo "o $A1" >> expected && git rev-list --graph --all > actual && test_cmp expected actual ' @@ -111,7 +111,7 @@ test_expect_success '--graph --simplify-by-decoration' ' echo "|/| " >> expected && echo "* | $A2" >> expected && echo "|/ " >> expected && - echo "* $A1" >> expected && + echo "o $A1" >> expected && git rev-list --graph --all --simplify-by-decoration > actual && test_cmp expected actual ' @@ -139,7 +139,7 @@ test_expect_success '--graph --simplify-by-decoration prune branch B' ' echo "* | $A3" >> expected && echo "|/ " >> expected && echo "* $A2" >> expected && - echo "* $A1" >> expected && + echo "o $A1" >> expected && git rev-list --graph --simplify-by-decoration --all > actual && test_cmp expected actual ' @@ -156,7 +156,7 @@ test_expect_success '--graph --full-history -- bar.txt' ' echo "| |/ " >> expected && echo "* | $A3" >> expected && echo "|/ " >> expected && - echo "* $A2" >> expected && + echo "o $A2" >> expected && git rev-list --graph --full-history --all -- bar.txt > actual && test_cmp expected actual ' @@ -170,7 +170,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' ' echo "* | $A5" >> expected && echo "* | $A3" >> expected && echo "|/ " >> expected && - echo "* $A2" >> expected && + echo "o $A2" >> expected && git rev-list --graph --full-history --simplify-merges --all \ -- bar.txt > actual && test_cmp expected actual @@ -183,7 +183,7 @@ test_expect_success '--graph -- bar.txt' ' echo "* $A3" >> expected && echo "| * $C4" >> expected && echo "|/ " >> expected && - echo "* $A2" >> expected && + echo "o $A2" >> expected && git rev-list --graph --all -- bar.txt > actual && test_cmp expected actual ' @@ -201,7 +201,7 @@ test_expect_success '--graph --sparse -- bar.txt' ' echo "| * $C1" >> expected && echo "|/ " >> expected && echo "* $A2" >> expected && - echo "* $A1" >> expected && + echo "o $A1" >> expected && git rev-list --graph --sparse --all -- bar.txt > actual && test_cmp expected actual ' -- 2.1.1 ``` ## Antoine Beaupré, 2015-07-27 19:37 Subject: Re: [PATCH] graph.c: visual difference on subsequent series Message-ID: <87twspe6ix.fsf@marcos.anarc.at> URL: https://gitlist.dev/e/87twspe6ix.fsf%40marcos.anarc.at In-Reply-To: <1415626412-573-1-git-send-email-anarcat@koumbit.org> ``` Any reason why this patch wasn't included / reviewed? Thanks, A. On 2014-11-10 08:33:32, Antoine Beaupré wrote: > For projects with separate history lines and, thus, multiple root-commits, the > linear arrangement of `git log --graph --oneline` does not allow the user to > spot where the sequence ends, giving the impression that it's a contiguous > history. E.g. > > History sequence A: a1 -- a2 -- a3 (root-commit) > History sequence B: b1 -- b2 -- b3 (root-commit) > > git log --graph --oneline > * a1 > * a2 > * a3 > * b1 > * b2 > * b3 > > In a GUI tool, the root-commit of each series would stand out on the graph. > > This modification changes the commit char to a different symbol ('o'), so users > of the command-line graph tool can easily identify root-commits and make sense > of where each series is limited to. > > git log --graph --oneline > * a1 > * a2 > o a3 > * b1 > * b2 > o b3 > > The 'o' character was chosen because it is the same character used in rev-list > to mark root commits. > > This patch is similar than the one provided by Milton Soares Filho in > 1382734287.31768.1.git.send.email.milton.soares.filho@gmail.com but was > implemented independently and uses the 'o' character instead of 'x'. > > Other solutions were discarded for those reasons: > > * line delimiters: we want to keep one commit per line > * tree indentation: it makes little sense with commit trees without > common history, and is more complicated to implement > > Signed-off-by: Antoine Beaupré > --- > revision.c | 8 ++++++-- > t/t4202-log.sh | 10 +++++----- > t/t6016-rev-list-graph-simplify-history.sh | 14 +++++++------- > 3 files changed, 18 insertions(+), 14 deletions(-) > > diff --git a/revision.c b/revision.c > index 75dda92..5f21e24 100644 > --- a/revision.c > +++ b/revision.c > @@ -3246,8 +3246,12 @@ char *get_revision_mark(const struct rev_info *revs, const struct commit *commit > return "<"; > else > return ">"; > - } else if (revs->graph) > - return "*"; > + } else if (revs->graph) { > + if (commit->parents) > + return "*"; > + else > + return "o"; > + } > else if (revs->cherry_mark) > return "+"; > return ""; > diff --git a/t/t4202-log.sh b/t/t4202-log.sh > index 99ab7ca..d11876e 100755 > --- a/t/t4202-log.sh > +++ b/t/t4202-log.sh > @@ -244,7 +244,7 @@ cat > expect < * fourth > * third > * second > -* initial > +o initial > EOF > > test_expect_success 'simple log --graph' ' > @@ -272,7 +272,7 @@ cat > expect <<\EOF > |/ > * third > * second > -* initial > +o initial > EOF > > test_expect_success 'log --graph with merge' ' > @@ -338,7 +338,7 @@ cat > expect <<\EOF > | > | second > | > -* commit tags/side-1~3 > +o commit tags/side-1~3 > Author: A U Thor > > initial > @@ -410,7 +410,7 @@ cat > expect <<\EOF > * | third > |/ > * second > -* initial > +o initial > EOF > > test_expect_success 'log --graph with merge' ' > @@ -799,7 +799,7 @@ cat >expect <<\EOF > | -one > | +ichi > | > -* commit COMMIT_OBJECT_NAME > +o commit COMMIT_OBJECT_NAME > Author: A U Thor > > initial > diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh > index f7181d1..74b6fc3 100755 > --- a/t/t6016-rev-list-graph-simplify-history.sh > +++ b/t/t6016-rev-list-graph-simplify-history.sh > @@ -81,7 +81,7 @@ test_expect_success '--graph --all' ' > echo "|/| " >> expected && > echo "* | $A2" >> expected && > echo "|/ " >> expected && > - echo "* $A1" >> expected && > + echo "o $A1" >> expected && > git rev-list --graph --all > actual && > test_cmp expected actual > ' > @@ -111,7 +111,7 @@ test_expect_success '--graph --simplify-by-decoration' ' > echo "|/| " >> expected && > echo "* | $A2" >> expected && > echo "|/ " >> expected && > - echo "* $A1" >> expected && > + echo "o $A1" >> expected && > git rev-list --graph --all --simplify-by-decoration > actual && > test_cmp expected actual > ' > @@ -139,7 +139,7 @@ test_expect_success '--graph --simplify-by-decoration prune branch B' ' > echo "* | $A3" >> expected && > echo "|/ " >> expected && > echo "* $A2" >> expected && > - echo "* $A1" >> expected && > + echo "o $A1" >> expected && > git rev-list --graph --simplify-by-decoration --all > actual && > test_cmp expected actual > ' > @@ -156,7 +156,7 @@ test_expect_success '--graph --full-history -- bar.txt' ' > echo "| |/ " >> expected && > echo "* | $A3" >> expected && > echo "|/ " >> expected && > - echo "* $A2" >> expected && > + echo "o $A2" >> expected && > git rev-list --graph --full-history --all -- bar.txt > actual && > test_cmp expected actual > ' > @@ -170,7 +170,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' ' > echo "* | $A5" >> expected && > echo "* | $A3" >> expected && > echo "|/ " >> expected && > - echo "* $A2" >> expected && > + echo "o $A2" >> expected && > git rev-list --graph --full-history --simplify-merges --all \ > -- bar.txt > actual && > test_cmp expected actual > @@ -183,7 +183,7 @@ test_expect_success '--graph -- bar.txt' ' > echo "* $A3" >> expected && > echo "| * $C4" >> expected && > echo "|/ " >> expected && > - echo "* $A2" >> expected && > + echo "o $A2" >> expected && > git rev-list --graph --all -- bar.txt > actual && > test_cmp expected actual > ' > @@ -201,7 +201,7 @@ test_expect_success '--graph --sparse -- bar.txt' ' > echo "| * $C1" >> expected && > echo "|/ " >> expected && > echo "* $A2" >> expected && > - echo "* $A1" >> expected && > + echo "o $A1" >> expected && > git rev-list --graph --sparse --all -- bar.txt > actual && > test_cmp expected actual > ' > -- > 2.1.1 > -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Enstein ``` ## Junio C Hamano, 2015-07-27 20:17 Subject: Re: [PATCH] graph.c: visual difference on subsequent series Message-ID: URL: https://gitlist.dev/e/xmqqegjticd7.fsf%40gitster.dls.corp.google.com In-Reply-To: <87twspe6ix.fsf@marcos.anarc.at> ``` Antoine Beaupré writes: > Any reason why this patch wasn't included / reviewed? > ... >> This patch is similar than the one provided by Milton Soares Filho in >> 1382734287.31768.1.git.send.email.milton.soares.filho@gmail.com but was >> implemented independently and uses the 'o' character instead of 'x'. The reason why Milton's patch was not taken after discussion [*1*] was not because its implementation was poor, but its design was not good. By overriding '*' '<' or '>' with x, it made it impossible to distinguish a root on the left side branch and a root on the right side branch. Is the design of your independent implementation the same except that 'o' is used instead of 'x'? Independent implementation does not make the same design magically better, if that is the case ;-) If the design is different, please explain how your patch solves the issue with Milton's design in your log message. For example, you could use the column arrangement to solve it, e.g. History sequence A: a1 -- a2 -- a3 (root-commit) History sequence B: b1 -- b2 -- b3 (root-commit) $ git log --graph --oneline A B * a1 * a2 * a3 * b1 * b2 * b3 $ git log --graph --oneline --left-right A...B < a1 < a2 < a3 > b1 > b2 > b3 I am not saying that the above would be the only way to do so; there may be other ways to solve the issue. [Reference] *1* http://thread.gmane.org/gmane.comp.version-control.git/236708/focus=236843 ``` ## Michael J Gruber, 2015-09-03 08:04 Subject: Re: [PATCH] graph.c: visual difference on subsequent series Message-ID: <55E7FEF3.2020400@drmicha.warpmail.net> URL: https://gitlist.dev/e/55E7FEF3.2020400%40drmicha.warpmail.net In-Reply-To: ``` Junio C Hamano venit, vidit, dixit 27.07.2015 22:17: > Antoine Beaupré writes: > >> Any reason why this patch wasn't included / reviewed? >> ... >>> This patch is similar than the one provided by Milton Soares Filho in >>> 1382734287.31768.1.git.send.email.milton.soares.filho@gmail.com but was >>> implemented independently and uses the 'o' character instead of 'x'. > > The reason why Milton's patch was not taken after discussion [*1*] > was not because its implementation was poor, but its design was not > good. By overriding '*' '<' or '>' with x, it made it impossible to > distinguish a root on the left side branch and a root on the right > side branch. > > Is the design of your independent implementation the same except > that 'o' is used instead of 'x'? Independent implementation does > not make the same design magically better, if that is the case ;-) Interestingly, the patch to the tests lists * to o changes only, no < or > to o. The reason is simply that the patch doesn't change anything for left nor right commits. I would say that is the best compromise since it does not change the overall layout, provides more information by default and does not override information that is requested specifically. If we want to put more information into log --graph simultaneously we should really go beyond ASCII and look at how tig does it, e.g. using unicode characters. > If the design is different, please explain how your patch solves the > issue with Milton's design in your log message. > > For example, you could use the column arrangement to solve it, e.g. > > History sequence A: a1 -- a2 -- a3 (root-commit) > History sequence B: b1 -- b2 -- b3 (root-commit) > > $ git log --graph --oneline A B > * a1 > * a2 > * a3 > * b1 > * b2 > * b3 > > $ git log --graph --oneline --left-right A...B > < a1 > < a2 > < a3 > > b1 > > b2 > > b3 > > I am not saying that the above would be the only way to do so; there > may be other ways to solve the issue. > > [Reference] > > *1* http://thread.gmane.org/gmane.comp.version-control.git/236708/focus=236843 > ``` ## Junio C Hamano, 2015-09-03 17:13 Subject: Re: [PATCH] graph.c: visual difference on subsequent series Message-ID: URL: https://gitlist.dev/e/xmqq613rl92s.fsf%40gitster.mtv.corp.google.com In-Reply-To: <55E7FEF3.2020400@drmicha.warpmail.net> ``` Michael J Gruber writes: >> Is the design of your independent implementation the same except >> that 'o' is used instead of 'x'? Independent implementation does >> not make the same design magically better, if that is the case ;-) > > Interestingly, the patch to the tests lists * to o changes only, no < or >> to o. Well, in that case, then the opposite but an equivalent problem exists in the design, no? It promises to make roots stand out by painting them as 'o', but it sometimes fails to do so. In other words, ... > The reason is simply that the patch doesn't change anything for left nor > right commits. I would say that is the best compromise since it does not > change the overall layout, provides more information by default and does > not override information that is requested specifically. ... it fails your last criteria. > If we want to put more information into log --graph simultaneously we > should really go beyond ASCII and look at how tig does it, e.g. using > unicode characters. That's another way to do so, but shifting columns to show where the history is not connected also does not change the overall layout, provides more information by default, etc., and a big plus is that it would be an approach to do so without having to go beyond ASCII. ``` ## Michael J Gruber, 2015-09-04 14:07 Subject: Re: [PATCH] graph.c: visual difference on subsequent series Message-ID: <55E9A5B2.5080606@drmicha.warpmail.net> URL: https://gitlist.dev/e/55E9A5B2.5080606%40drmicha.warpmail.net In-Reply-To: ``` Junio C Hamano venit, vidit, dixit 03.09.2015 19:13: > Michael J Gruber writes: > >>> Is the design of your independent implementation the same except >>> that 'o' is used instead of 'x'? Independent implementation does >>> not make the same design magically better, if that is the case ;-) >> >> Interestingly, the patch to the tests lists * to o changes only, no < or >>> to o. > > Well, in that case, then the opposite but an equivalent problem > exists in the design, no? It promises to make roots stand out by > painting them as 'o', but it sometimes fails to do so. In other > words, ... > >> The reason is simply that the patch doesn't change anything for left nor >> right commits. I would say that is the best compromise since it does not >> change the overall layout, provides more information by default and does >> not override information that is requested specifically. > > ... it fails your last criteria. How would it? "--left-right" information is requested specifically and not overridden. Root information is not requested specifically [by the user]. >> If we want to put more information into log --graph simultaneously we >> should really go beyond ASCII and look at how tig does it, e.g. using >> unicode characters. > > That's another way to do so, but shifting columns to show where the > history is not connected also does not change the overall layout, > provides more information by default, etc., and a big plus is that > it would be an approach to do so without having to go beyond ASCII. That would consume more horizontal space and annoy at least some people. Alternatively, we could use more vertical space and annoy at least some (other?) people. In fact, I tend to think that horizontal space is more "precious" than vertical space due to the common orientation of scrolling... If we don't mind an increase in vertical spacing there are more issues that could be solved, for example the merge point description sticking visually to the commits above rather than the merged branch in the typical old..new scenario. In fact, both issues would be solved be adding an extra line after a root commit (be it "real" root or boundary-wise). Michael ``` ## Junio C Hamano, 2015-09-04 16:08 Subject: Re: [PATCH] graph.c: visual difference on subsequent series Message-ID: URL: https://gitlist.dev/e/xmqq37yugobh.fsf%40gitster.mtv.corp.google.com In-Reply-To: <55E9A5B2.5080606@drmicha.warpmail.net> ``` Michael J Gruber writes: > How would it? "--left-right" information is requested specifically and > not overridden. Root information is not requested specifically [by the > user]. If this "highlight root prominently" were a config, then using both config and --left-right would mean one of them needs to give. If this were always on, then the act of the user running "git log" alone is a sign that the user explicitly asked the log to be shown with the new world order, i.e. the root is promised to be shown visible. Either way, the user is not getting what s/he asked. >>> If we want to put more information into log --graph simultaneously we >>> should really go beyond ASCII and look at how tig does it, e.g. using >>> unicode characters. >> >> That's another way to do so, but shifting columns to show where the >> history is not connected also does not change the overall layout, >> provides more information by default, etc., and a big plus is that >> it would be an approach to do so without having to go beyond ASCII. > > That would consume more horizontal space and annoy at least some people. I sense that we are working from different perceptions of what "shifting columns" should look like. A history that reaches two roots would be shown like this, with or without any special treatment for root: * tip |\ | * tip of the side branch * | tip of the trunk * | second of the trunk * | root of the trunk * second of the side branch * root of the side branch so it does not give us any more "wasted space" issue with or without "showing root more prominently". The case where we would see differences is to have two or more totally disjoint histories. But "shifting columns" does not have to draw that case like this: * tip of history A | * tip of history B * | second of history A * | root of history A * second of history B * third of history B * fourth of history B * fifth of history B * root of history B It can do this instead to save horizontal space (which I agree with you is the more precious one than the vertical one): * tip of history A | * tip of history B * | second of history A * | root of history A * second of history B / * third of history B * fourth of history B * fifth of history B * root of history B It does spend more space around the root of each history (in this case, history A) when it shifts the column for history B to the space now vacated by history A in order to save horizontal space. But drawing the graph around the root differently from other parts is exactly to show roots more prominently; it draws the users' eyes. Here is another example of drawing the same history. If the traversal is topologica:, "shifting columns" does not have to draw this: * tip of history A * second of history A * root of history A * tip of history B * second of history B * third of history B * fourth of history B * fifth of history B * root of history B It can do this instead: * tip of history A * second of history A * root of history A * tip of history B / * second of history B * third of history B * fourth of history B * fifth of history B * root of history B Again I am not saying that "shifting columns" is the only way we can do this, and there may be other ways to do this without losing information. Going beyond ASCII as you hinted would be one example. ```