{"thread":{"id":"35201","subject":"[PATCH] graph.c: visual difference on subsequent series","startedAt":"2013-10-25T20:51:27Z","lastAt":"2013-10-25T20:51:27Z","messageCount":1,"participants":["Milton Soares Filho"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"229526","messageId":"1382734287-31768-1-git-send-email-milton.soares.filho@gmail.com","threadId":"35201","inReplyTo":null,"subject":"[PATCH] graph.c: visual difference on subsequent series","fromName":"Milton Soares Filho","fromEmail":"milton.soares.filho@gmail.com","sentAt":"2013-10-25T20:51:27Z","receivedAt":"2013-10-25T20:51:27Z","isPatch":true,"sender":{"key":"milton.soares.filho@gmail.com","avatar":"https://gravatar.com/avatar/d31bcd8aa5b1556462c04ce486389a9daf6096b741aa6f546e5a6f0010f1f4c4?d=mp&s=160"},"body":"For projects with separate history lines and, thus, multiple root-commits, the\nlinear arrangement of `git log --graph --oneline` does not allow the user to\nspot where the sequence ends, giving the impression that it's a contiguous\nhistory. E.g.\n\nHistory sequence A: a1 -- a2 -- a3 (root-commit)\nHistory sequence B: b1 -- b2 -- b3 (root-commit)\n\n    git log --graph --oneline\n    * a1\n    * a2\n    * a3\n    * b1\n    * b2\n    * b3\n\nIn a GUI tool, the root-commit of each series would stand out on the graph.\n\nThis modification changes the commit char to a different symbol ('x'), so users\nof the command-line graph tool can easily identify root-commits and make sense\nof where each series is limited to.\n\n    git log --graph --oneline\n    * a1\n    * a2\n    x a3\n    * b1\n    * b2\n    x b3\n\nUPDATE: dealing with the mark at get_revision_mark() to address Junio C Hamano\nconcerns and give it a proper priority:\n\n> It is unclear why the update goes to this function. At the first\n> glance, I feel that it would be more sensible to add the equivalent\n> code to get_revision_mark()---we do not have to worry about what\n> else, other than calling get_revision_mark() and adding it to sb,\n> would be skipped by the added \"return\" when we later have to update\n> this function and add more code after the existing strbuf_addstr().\n>\n> The change implemented your way will lose other information when a\n> root commit is at the boundary, marked as uninteresting, or on the\n> left/right side of traversal (when --left-right is requested).  I\n> think these pieces of information your patch seems to be losing are\n> a lot more relevant than \"have we hit the root?\", especially in the\n> majority of repositories where there is only one root commit.\n\nSigned-off-by: Milton Soares Filho <milton.soares.filho@gmail.com>\n---\n revision.c | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/revision.c b/revision.c\nindex 0173e01..ab0447f 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -3066,7 +3066,9 @@ char *get_revision_mark(const struct rev_info *revs, const struct commit *commit\n \t\t\treturn \"<\";\n \t\telse\n \t\t\treturn \">\";\n-\t} else if (revs->graph)\n+\t} else if (revs->graph && commit->parents == NULL)\n+\t\treturn \"x\"; /* diverges root-commits in subsequent series */\n+\telse if (revs->graph)\n \t\treturn \"*\";\n \telse if (revs->cherry_mark)\n \t\treturn \"+\";\n-- \n1.8.1.2\n"}]}