{"thread":{"id":"16151","subject":"[Q] Abbreviated history graph?","startedAt":"2008-11-03T13:39:11Z","lastAt":"2008-11-04T21:33:35Z","messageCount":18,"participants":["Brian Foster","Santi Béjar","Linus Torvalds","Robin Rosenberg","Junio C Hamano","Clemens Buchacher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94759","messageId":"200811031439.12111.brian.foster@innova-card.com","threadId":"16151","inReplyTo":null,"subject":"[Q] Abbreviated history graph?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2008-11-03T13:39:11Z","receivedAt":"2008-11-03T13:39:11Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"\nHello,\n\n  A colleague and I recently wanted to examine the\n history in a broad sense without worrying too much\n about the individual commits.  What we (think we)\n wanted is a ‘gitk --all’ history graph showing only\n “named” historical points; i.e., tags and branch\n HEADs, perhaps with an indication of whether or not\n it's a “linear” change sequence that leads from one\n to another.  That is, hypothetically, if the history\n looks something like (where ‘A’ &tc has a name as\n per above, and ‘*’ does not):\n\n     A--->*--->*--->C--->D--->*----->E\n      \\                   \\         /\n       \\->*-->B            \\->*--->*--->F\n\n What we wanted to see is something like:\n\n     A------>C--->D--->E\n      \\       \\       /\n       \\->B    \\-----/--->F\n\n Is there some way of doing something similar to that\n (git v1.6.0.2)?  In addition to ‘gitk’, we also (rather\n quickly!) tried both ‘qgit’ and ‘giggle’, but without\n any apparent success.\n\ncheers!\n\t-blf-\n\n-- \n“How many surrealists does it take to   | Brian Foster\n change a lightbulb? Three. One calms   | somewhere in south of France\n the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” |      http://www.stopesso.com\n"},{"id":"94762","messageId":"adf1fd3d0811030620x1bc53db3y2afb26242e9906ac@mail.gmail.com","threadId":"16151","inReplyTo":"200811031439.12111.brian.foster@innova-card.com","subject":"Re: [Q] Abbreviated history graph?","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-11-03T14:20:30Z","receivedAt":"2008-11-03T14:20:30Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Nov 3, 2008 at 2:39 PM, Brian Foster\n<brian.foster@innova-card.com> wrote:\n>\n> Hello,\n>\n>  A colleague and I recently wanted to examine the\n>  history in a broad sense without worrying too much\n>  about the individual commits.  What we (think we)\n>  wanted is a 'gitk --all' history graph showing only\n>  \"named\" historical points; i.e., tags and branch\n>  HEADs, perhaps with an indication of whether or not\n>  it's a \"linear\" change sequence that leads from one\n>  to another.  That is, hypothetically, if the history\n>  looks something like (where 'A' &tc has a name as\n>  per above, and '*' does not):\n>\n>     A--->*--->*--->C--->D--->*----->E\n>      \\                   \\         /\n>       \\->*-->B            \\->*--->*--->F\n>\n>  What we wanted to see is something like:\n>\n>     A------>C--->D--->E\n>      \\       \\       /\n>       \\->B    \\-----/--->F\n>\n>  Is there some way of doing something similar to that\n>  (git v1.6.0.2)?  In addition to 'gitk', we also (rather\n>  quickly!) tried both 'qgit' and 'giggle', but without\n>  any apparent success.\n\nNot in git.git but you can use the script at the bottom (also attached\nin case it is whitespace damage).\nIt could be much faster if \"git log\" stops when finding a tag/branch.\n\nHTH,\nSanti\n\n[git-overview]\n#!/bin/sh\n\nTMP=$(mktemp -t git-overview.XXXXXXXXXXX)\ntrap 'rm -f \"$TMP\"' 0 1 2 3 15\n\ngit log --reverse --pretty=short --decorate --pretty=format:%H%d $@ |\\\n    awk 'BEGIN {FS=\"[ ,()]*\"} NF>=2 {print $1}' | \\\n    while read hash ; do\n    # Independent tags/branches parents:\n    # Notes:\n    #   * -n 1000 to limit the search, ideally \"git log\" could stop\n    #     traversing the history when hits a tag/branch tip\n    #   * head -n 25 because \"git show-branch --independent\" has this limit\n    ancestors=$(git log -n 1000 --pretty=short --decorate\n--pretty=format:%H%d $hash^@ |\\\n    awk 'BEGIN {FS=\"[ ,()]*\"} NF>=2 {print $1}' | head -n 25)\n    if [ -n \"$ancestors\" ] ; then\n\techo $hash $(git show-branch --independent $ancestors)\n    else\n\techo $hash\n    fi\ndone > $TMP\nGIT_GRAFT_FILE=$TMP gitk \"$@\" -d\n"},{"id":"94766","messageId":"adf1fd3d0811030655k9a6d48fh9fb046b3a741f4c7@mail.gmail.com","threadId":"16151","inReplyTo":"adf1fd3d0811030620x1bc53db3y2afb26242e9906ac@mail.gmail.com","subject":"Re: [Q] Abbreviated history graph?","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-11-03T14:55:13Z","receivedAt":"2008-11-03T14:55:13Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Nov 3, 2008 at 3:20 PM, Santi Béjar <santi@agolina.net> wrote:\n> On Mon, Nov 3, 2008 at 2:39 PM, Brian Foster\n> <brian.foster@innova-card.com> wrote:\n>>\n>> Hello,\n>>\n>>  A colleague and I recently wanted to examine the\n>>  history in a broad sense without worrying too much\n>>  about the individual commits.  What we (think we)\n>>  wanted is a 'gitk --all' history graph showing only\n>>  \"named\" historical points; i.e., tags and branch\n>>  HEADs, perhaps with an indication of whether or not\n>>  it's a \"linear\" change sequence that leads from one\n>>  to another.  That is, hypothetically, if the history\n>>  looks something like (where 'A' &tc has a name as\n>>  per above, and '*' does not):\n>>\n>>     A--->*--->*--->C--->D--->*----->E\n>>      \\                   \\         /\n>>       \\->*-->B            \\->*--->*--->F\n>>\n>>  What we wanted to see is something like:\n>>\n>>     A------>C--->D--->E\n>>      \\       \\       /\n>>       \\->B    \\-----/--->F\n>>\n>>  Is there some way of doing something similar to that\n>>  (git v1.6.0.2)?  In addition to 'gitk', we also (rather\n>>  quickly!) tried both 'qgit' and 'giggle', but without\n>>  any apparent success.\n>\n> Not in git.git but you can use the script at the bottom (also attached\n> in case it is whitespace damage).\n> It could be much faster if \"git log\" stops when finding a tag/branch.\n>\n\nJust to add that it would be great if gitk's \"List references\" showed\nthem in this way (possibly with a toggle to show them in alphabetical\norder).\n\nSanti\n"},{"id":"94770","messageId":"200811031646.20404.brian.foster@innova-card.com","threadId":"16151","inReplyTo":"adf1fd3d0811030620x1bc53db3y2afb26242e9906ac@mail.gmail.com","subject":"Re: [Q] Abbreviated history graph?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2008-11-03T15:46:20Z","receivedAt":"2008-11-03T15:46:20Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"On Monday 03 November 2008 15:20:30 Santi Béjar wrote:\n>[ ... ]\n> >  Is there some way of doing something similar [ the example ]\n> >  (git v1.6.0.2)?  In addition to 'gitk', we also (rather\n> >  quickly!) tried both 'qgit' and 'giggle', but without\n> >  any apparent success.\n> \n> Not in git.git but you can use the script at the bottom [ ... ].\n\nSanti,\n\n   Thanks.  Unfortunately, neither I nor my colleague can try\n  it at the moment:  It uses  `git log --pretty=format:%d'\n  which is very new (added c.9-Sept) and not in the versions\n  of git we are currently using.  End result is the tempfile\n  is always empty, and hence `gitk' shows everything.\n\ncheers!\n\t-blf-\n\n-- \n“How many surrealists does it take to   | Brian Foster\n change a lightbulb? Three. One calms   | somewhere in south of France\n the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” |      http://www.stopesso.com\n"},{"id":"94772","messageId":"adf1fd3d0811030808r6d795b54g9fd5b25ce5fe3cdb@mail.gmail.com","threadId":"16151","inReplyTo":"200811031646.20404.brian.foster@innova-card.com","subject":"Re: [Q] Abbreviated history graph?","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-11-03T16:08:00Z","receivedAt":"2008-11-03T16:08:00Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Nov 3, 2008 at 4:46 PM, Brian Foster\n<brian.foster@innova-card.com> wrote:\n> On Monday 03 November 2008 15:20:30 Santi Béjar wrote:\n>>[ ... ]\n>> >  Is there some way of doing something similar [ the example ]\n>> >  (git v1.6.0.2)?  In addition to 'gitk', we also (rather\n>> >  quickly!) tried both 'qgit' and 'giggle', but without\n>> >  any apparent success.\n>>\n>> Not in git.git but you can use the script at the bottom [ ... ].\n>\n> Santi,\n>\n>   Thanks.  Unfortunately, neither I nor my colleague can try\n>  it at the moment:  It uses  `git log --pretty=format:%d'\n>  which is very new (added c.9-Sept) and not in the versions\n>  of git we are currently using.  End result is the tempfile\n>  is always empty, and hence `gitk' shows everything.\n\n\nUps! So you could get the same information with the uglier (and slower):\n\n$ git log --reverse --pretty=short --decorate | grep ^commit\n\nbut then you should change \"NF>=2\" with \"NF>=3\", or use an older one I\nsent to the list (search for git-overview).\n\nSanti\n"},{"id":"94851","messageId":"alpine.LFD.2.00.0811031129060.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"200811031439.12111.brian.foster@innova-card.com","subject":"Re: [Q] Abbreviated history graph?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T19:32:37Z","receivedAt":"2008-11-03T19:32:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 Nov 2008, Brian Foster wrote:\n> \n>   A colleague and I recently wanted to examine the\n>  history in a broad sense without worrying too much\n>  about the individual commits.  What we (think we)\n>  wanted is a ‘gitk --all’ history graph showing only\n>  “named” historical points;\n\nOk, this is actually really easy to do with git. We have all the \ninfrastructure in place, and what you're asking for is fundamentally \nreally just an odd form of commit history simplification. Instead of \ncomparing the *contents* of the commits (the trees) to see if they are \ninteresting, you'd only check if there is a decoration (ie a tag or a \nbranch) pointing to the commit.\n\nI'll post a simple series of four commits in a moment. They're all \ntrivial, and the first three are just setting stuff up (in fact, the very \nfirst one is a commit I've already posted, and it's technically totally \nunrelated, but since it touches the same area as one of the other ones, \nI'm too lazy to try to separate it out).\n\nPatchbombing to commence in 5.. 4.. 3.. 2.. 1..\n\n\t\tLinus\n"},{"id":"94798","messageId":"alpine.LFD.2.00.0811031132520.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031129060.3419@nehalem.linux-foundation.org","subject":"[PATCH 1/4] Add a 'source' decorator for commits","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T19:33:53Z","receivedAt":"2008-11-03T19:33:53Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nFrom: Linus Torvalds <torvalds@linux-foundation.org>\nDate: Mon, 27 Oct 2008 12:51:59 -0700\n\nWe already support decorating commits by tags or branches that point to\nthem, but especially when we are looking at multiple branches together,\nwe sometimes want to see _how_ we reached a particular commit.\n\nWe can abuse the '->util' field in the commit to keep track of that as\nwe walk the commit lists, and get a reasonably useful view into which\nbranch or tag first reaches that commit.\n\nOf course, if the commit is reachable through multiple sources (which is\ncommon), our particular choice of \"first\" reachable is entirely random\nand depends on the particular path we happened to follow.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n\nThis is strictly unrelated to the rest, but as mentioned, it touches the \nsame areas, and I'm too lazy to split it out. I had it in my tree. It \nwon't hurt.\n\n builtin-log.c      |    2 ++\n builtin-rev-list.c |    2 +-\n log-tree.c         |    8 +++++---\n log-tree.h         |    2 +-\n revision.c         |    4 ++++\n revision.h         |    1 +\n 6 files changed, 14 insertions(+), 5 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex a0944f7..176cbce 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -56,6 +56,8 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,\n \t\tif (!strcmp(arg, \"--decorate\")) {\n \t\t\tload_ref_decorations();\n \t\t\tdecorate = 1;\n+\t\t} else if (!strcmp(arg, \"--source\")) {\n+\t\t\trev->show_source = 1;\n \t\t} else\n \t\t\tdie(\"unrecognized argument: %s\", arg);\n \t}\ndiff --git a/builtin-rev-list.c b/builtin-rev-list.c\nindex 06cdeb7..857742a 100644\n--- a/builtin-rev-list.c\n+++ b/builtin-rev-list.c\n@@ -100,7 +100,7 @@ static void show_commit(struct commit *commit)\n \t\t\tchildren = children->next;\n \t\t}\n \t}\n-\tshow_decorations(commit);\n+\tshow_decorations(&revs, commit);\n \tif (revs.commit_format == CMIT_FMT_ONELINE)\n \t\tputchar(' ');\n \telse\ndiff --git a/log-tree.c b/log-tree.c\nindex cec3c06..cf7947b 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -52,11 +52,13 @@ static void show_parents(struct commit *commit, int abbrev)\n \t}\n }\n \n-void show_decorations(struct commit *commit)\n+void show_decorations(struct rev_info *opt, struct commit *commit)\n {\n \tconst char *prefix;\n \tstruct name_decoration *decoration;\n \n+\tif (opt->show_source && commit->util)\n+\t\tprintf(\" %s\", (char *) commit->util);\n \tdecoration = lookup_decoration(&name_decoration, &commit->object);\n \tif (!decoration)\n \t\treturn;\n@@ -279,7 +281,7 @@ void show_log(struct rev_info *opt)\n \t\tfputs(diff_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);\n \t\tif (opt->print_parents)\n \t\t\tshow_parents(commit, abbrev_commit);\n-\t\tshow_decorations(commit);\n+\t\tshow_decorations(opt, commit);\n \t\tif (opt->graph && !graph_is_commit_finished(opt->graph)) {\n \t\t\tputchar('\\n');\n \t\t\tgraph_show_remainder(opt->graph);\n@@ -352,7 +354,7 @@ void show_log(struct rev_info *opt)\n \t\t\tprintf(\" (from %s)\",\n \t\t\t       diff_unique_abbrev(parent->object.sha1,\n \t\t\t\t\t\t  abbrev_commit));\n-\t\tshow_decorations(commit);\n+\t\tshow_decorations(opt, commit);\n \t\tprintf(\"%s\", diff_get_color_opt(&opt->diffopt, DIFF_RESET));\n \t\tif (opt->commit_format == CMIT_FMT_ONELINE) {\n \t\t\tputchar(' ');\ndiff --git a/log-tree.h b/log-tree.h\nindex 3c8127b..f2a9008 100644\n--- a/log-tree.h\n+++ b/log-tree.h\n@@ -12,7 +12,7 @@ int log_tree_diff_flush(struct rev_info *);\n int log_tree_commit(struct rev_info *, struct commit *);\n int log_tree_opt_parse(struct rev_info *, const char **, int);\n void show_log(struct rev_info *opt);\n-void show_decorations(struct commit *commit);\n+void show_decorations(struct rev_info *opt, struct commit *commit);\n void log_write_email_headers(struct rev_info *opt, const char *name,\n \t\t\t     const char **subject_p,\n \t\t\t     const char **extra_headers_p,\ndiff --git a/revision.c b/revision.c\nindex 2f646de..d45f05a 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -199,6 +199,8 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object\n \t\t\tmark_parents_uninteresting(commit);\n \t\t\trevs->limited = 1;\n \t\t}\n+\t\tif (revs->show_source && !commit->util)\n+\t\t\tcommit->util = (void *) name;\n \t\treturn commit;\n \t}\n \n@@ -484,6 +486,8 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,\n \n \t\tif (parse_commit(p) < 0)\n \t\t\treturn -1;\n+\t\tif (revs->show_source && !p->util)\n+\t\t\tp->util = commit->util;\n \t\tp->object.flags |= left_flag;\n \t\tif (!(p->object.flags & SEEN)) {\n \t\t\tp->object.flags |= SEEN;\ndiff --git a/revision.h b/revision.h\nindex 2fdb2dd..51a4863 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -53,6 +53,7 @@ struct rev_info {\n \t\t\tleft_right:1,\n \t\t\trewrite_parents:1,\n \t\t\tprint_parents:1,\n+\t\t\tshow_source:1,\n \t\t\treverse:1,\n \t\t\treverse_output_stage:1,\n \t\t\tcherry_pick:1,\n-- \n1.6.0.3.616.gf1239d6.dirty\n"},{"id":"94799","messageId":"alpine.LFD.2.00.0811031133590.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031132520.3419@nehalem.linux-foundation.org","subject":"[PATCH 2/4] revision: make tree comparison functions take commits rather than trees","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T19:35:35Z","receivedAt":"2008-11-03T19:35:35Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nFrom: Linus Torvalds <torvalds@linux-foundation.org>\nDate: Mon, 3 Nov 2008 10:45:41 -0800\nSubject: [PATCH 2/4] revision: make tree comparison functions take commits rather than trees\n\nThis will make it easier to do various clever things that don't depend\non the pure tree contents.  It also makes the parameter passing much\nsimpler - the callers doesn't really look at trees anywhere else, and\nit's really the function that should look at the low-level details.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n\nThis is a trivial no-op change that just passes commits instead of trees \nto the commit compare functions. The whole point is that we can now start \ncomparing them based on not just contents of the trees, but other \nattributes too.\n\nThe patch makes no semantic changes. Just preparation.\n\n revision.c |   14 +++++++++-----\n 1 files changed, 9 insertions(+), 5 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex d45f05a..56b09eb 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -294,8 +294,11 @@ static void file_change(struct diff_options *options,\n \tDIFF_OPT_SET(options, HAS_CHANGES);\n }\n \n-static int rev_compare_tree(struct rev_info *revs, struct tree *t1, struct tree *t2)\n+static int rev_compare_tree(struct rev_info *revs, struct commit *parent, struct commit *commit)\n {\n+\tstruct tree *t1 = parent->tree;\n+\tstruct tree *t2 = commit->tree;\n+\n \tif (!t1)\n \t\treturn REV_TREE_NEW;\n \tif (!t2)\n@@ -308,12 +311,13 @@ static int rev_compare_tree(struct rev_info *revs, struct tree *t1, struct tree\n \treturn tree_difference;\n }\n \n-static int rev_same_tree_as_empty(struct rev_info *revs, struct tree *t1)\n+static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit)\n {\n \tint retval;\n \tvoid *tree;\n \tunsigned long size;\n \tstruct tree_desc empty, real;\n+\tstruct tree *t1 = commit->tree;\n \n \tif (!t1)\n \t\treturn 0;\n@@ -347,7 +351,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \t\treturn;\n \n \tif (!commit->parents) {\n-\t\tif (rev_same_tree_as_empty(revs, commit->tree))\n+\t\tif (rev_same_tree_as_empty(revs, commit))\n \t\t\tcommit->object.flags |= TREESAME;\n \t\treturn;\n \t}\n@@ -367,7 +371,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \t\t\tdie(\"cannot simplify commit %s (because of %s)\",\n \t\t\t    sha1_to_hex(commit->object.sha1),\n \t\t\t    sha1_to_hex(p->object.sha1));\n-\t\tswitch (rev_compare_tree(revs, p->tree, commit->tree)) {\n+\t\tswitch (rev_compare_tree(revs, p, commit)) {\n \t\tcase REV_TREE_SAME:\n \t\t\ttree_same = 1;\n \t\t\tif (!revs->simplify_history || (p->object.flags & UNINTERESTING)) {\n@@ -387,7 +391,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)\n \n \t\tcase REV_TREE_NEW:\n \t\t\tif (revs->remove_empty_trees &&\n-\t\t\t    rev_same_tree_as_empty(revs, p->tree)) {\n+\t\t\t    rev_same_tree_as_empty(revs, p)) {\n \t\t\t\t/* We are adding all the specified\n \t\t\t\t * paths from this parent, so the\n \t\t\t\t * history beyond this parent is not\n-- \n1.6.0.3.616.gf1239d6.dirty\n"},{"id":"94800","messageId":"alpine.LFD.2.00.0811031135410.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031133590.3419@nehalem.linux-foundation.org","subject":"[PATCH 3/4] Make '--decorate' set an explicit 'show_decorations' flag","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T19:39:48Z","receivedAt":"2008-11-03T19:39:48Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nFrom: Linus Torvalds <torvalds@linux-foundation.org>\nDate: Mon, 3 Nov 2008 11:23:57 -0800\nSubject: [PATCH 3/4] Make '--decorate' set an explicit 'show_decorations' flag\n\nWe will want to add decorations without necessarily showing them, so add\nan explicit revisions info flag as to whether we're showing decorations\nor not.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n\nAnother really trivial preparatory patch. Instead of writing to a totally \nunused and pointless local variable (yeah, don't ask me why it does that, \nit's probably my brainfart from long ago), set a \"revs->show_decorations\" \nflag that we actually _use_ to decide if we want to show decorations or \nnot when outputting logs.\n\nThis makes no semantic difference, since there are only two users of \ndecorations:\n - format_decoration() which does everything by hand\n - show_decorations() that now looks at the flag that we set when we \n   preload them.\n\nIt _will_ matter in the next commit, though. Because soon we'll start \nloading decorations without actually wanting to necessarily show them!\n\n builtin-log.c |    3 +--\n log-tree.c    |    2 ++\n revision.h    |    1 +\n 3 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-log.c b/builtin-log.c\nindex 176cbce..82ea07b 100644\n--- a/builtin-log.c\n+++ b/builtin-log.c\n@@ -28,7 +28,6 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,\n \t\t      struct rev_info *rev)\n {\n \tint i;\n-\tint decorate = 0;\n \n \trev->abbrev = DEFAULT_ABBREV;\n \trev->commit_format = CMIT_FMT_DEFAULT;\n@@ -55,7 +54,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,\n \t\tconst char *arg = argv[i];\n \t\tif (!strcmp(arg, \"--decorate\")) {\n \t\t\tload_ref_decorations();\n-\t\t\tdecorate = 1;\n+\t\t\trev->show_decorations = 1;\n \t\t} else if (!strcmp(arg, \"--source\")) {\n \t\t\trev->show_source = 1;\n \t\t} else\ndiff --git a/log-tree.c b/log-tree.c\nindex cf7947b..5444f08 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -59,6 +59,8 @@ void show_decorations(struct rev_info *opt, struct commit *commit)\n \n \tif (opt->show_source && commit->util)\n \t\tprintf(\" %s\", (char *) commit->util);\n+\tif (!opt->show_decorations)\n+\t\treturn;\n \tdecoration = lookup_decoration(&name_decoration, &commit->object);\n \tif (!decoration)\n \t\treturn;\ndiff --git a/revision.h b/revision.h\nindex 51a4863..0a1806a 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -54,6 +54,7 @@ struct rev_info {\n \t\t\trewrite_parents:1,\n \t\t\tprint_parents:1,\n \t\t\tshow_source:1,\n+\t\t\tshow_decorations:1,\n \t\t\treverse:1,\n \t\t\treverse_output_stage:1,\n \t\t\tcherry_pick:1,\n-- \n1.6.0.3.616.gf1239d6.dirty\n"},{"id":"94802","messageId":"alpine.LFD.2.00.0811031139520.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031135410.3419@nehalem.linux-foundation.org","subject":"[PATCH 4/4] Add support for 'namespace' history simplification","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T19:43:00Z","receivedAt":"2008-11-03T19:43:00Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nFrom: Linus Torvalds <torvalds@linux-foundation.org>\nDate: Mon, 3 Nov 2008 11:25:46 -0800\nSubject: [PATCH 4/4] Add support for 'namespace' history simplification\n\nMaybe this is mis-named, but what it does is to simplify history not by\nthe contents of the tree, but whether a commit has been named (ie it's\nreferred to by some branch or tag) or not.\n\nThis makes it possible to see the relationship between different named\ncommits, without actually seeing any of the details.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n\nThis is the actual real meat of the logic, and it's really trivial. The \nactual code is really just a simple\n\n    if (simplify-by-namespace)\n        return lookup_decoration(..) ? REV_TREE_DIFFERENT : REV_TREE_SAME;\n\nbut it's a few more lines of addition than that because of parsing the \nargument and setting the appropriate flags, and writing the above \ntwo-liner as five lines with a comment in order to make it more readable.\n\nNo docs. I don't do docs. But you can use it like so:\n\n\tgitk --simplify-namespace\n\nand you're all done. \n\nTa-daa!\n\n\n revision.c |   20 ++++++++++++++++++++\n revision.h |    1 +\n 2 files changed, 21 insertions(+), 0 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex 56b09eb..b48e626 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -11,6 +11,7 @@\n #include \"reflog-walk.h\"\n #include \"patch-ids.h\"\n #include \"decorate.h\"\n+#include \"log-tree.h\"\n \n volatile show_early_output_fn_t show_early_output;\n \n@@ -301,6 +302,17 @@ static int rev_compare_tree(struct rev_info *revs, struct commit *parent, struct\n \n \tif (!t1)\n \t\treturn REV_TREE_NEW;\n+\n+\t/*\n+\t * If we do history simplification by _name_, ignore the\n+\t * actual tree contents, and just check if we have a\n+\t * decoration\n+\t */\n+\tif (revs->simplify_namespace) {\n+\t\tstruct name_decoration *name;\n+\t\tname = lookup_decoration(&name_decoration, &commit->object);\n+\t\treturn name ? REV_TREE_DIFFERENT : REV_TREE_SAME;\n+\t}\n \tif (!t2)\n \t\treturn REV_TREE_DIFFERENT;\n \ttree_difference = REV_TREE_SAME;\n@@ -1041,6 +1053,14 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg\n \t\trevs->rewrite_parents = 1;\n \t\trevs->simplify_history = 0;\n \t\trevs->limited = 1;\n+\t} else if (!strcmp(arg, \"--simplify-namespace\")) {\n+\t\trevs->simplify_merges = 1;\n+\t\trevs->rewrite_parents = 1;\n+\t\trevs->simplify_history = 0;\n+\t\trevs->simplify_namespace = 1;\n+\t\trevs->limited = 1;\n+\t\trevs->prune = 1;\n+\t\tload_ref_decorations();\n \t} else if (!strcmp(arg, \"--date-order\")) {\n \t\trevs->lifo = 0;\n \t\trevs->topo_order = 1;\ndiff --git a/revision.h b/revision.h\nindex 0a1806a..bd1ec0d 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -43,6 +43,7 @@ struct rev_info {\n \t\t\tlifo:1,\n \t\t\ttopo_order:1,\n \t\t\tsimplify_merges:1,\n+\t\t\tsimplify_namespace:1,\n \t\t\ttag_objects:1,\n \t\t\ttree_objects:1,\n \t\t\tblob_objects:1,\n-- \n1.6.0.3.616.gf1239d6.dirty\n"},{"id":"94803","messageId":"alpine.LFD.2.00.0811031211180.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031129060.3419@nehalem.linux-foundation.org","subject":"Re: [Q] Abbreviated history graph?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T20:15:05Z","receivedAt":"2008-11-03T20:15:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 Nov 2008, Linus Torvalds wrote:\n>\n> I'll post a simple series of four commits in a moment. They're all \n> trivial, and the first three are just setting stuff up (in fact, the very \n> first one is a commit I've already posted, and it's technically totally \n> unrelated, but since it touches the same area as one of the other ones, \n> I'm too lazy to try to separate it out).\n\nSide note: it's certainly possible that we could improve on this. Right \nnow, \"--simplify-namespace\" will totally override any path simplification, \nso you can't get a combination of pathnames _and_ naming commits. I don't \nknow exactly what the rules should be, but I could imagine that we could \ndo something like:\n\n - if no pathnames are given, work the way the current patch-series works.\n\n - if path-names are given, make rev_compare_tree() truen \n   REV_TREE_DIFFERENT if a name decoration _or_ a tree difference exists.\n\nAnyway, that's a fairly trivial extension to the idea, and doesn't really \nmatter for the basic code. It can easily be left for later.\n\n\t\tLinus\n"},{"id":"94806","messageId":"alpine.LFD.2.00.0811031233430.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031211180.3419@nehalem.linux-foundation.org","subject":"Re: [Q] Abbreviated history graph?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T20:34:06Z","receivedAt":"2008-11-03T20:34:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 Nov 2008, Linus Torvalds wrote:\n> \n> Side note: it's certainly possible that we could improve on this. Right \n> now, \"--simplify-namespace\" will totally override any path simplification, \n> so you can't get a combination of pathnames _and_ naming commits. I don't \n> know exactly what the rules should be, but I could imagine that we could \n> do something like:\n> \n>  - if no pathnames are given, work the way the current patch-series works.\n> \n>  - if path-names are given, make rev_compare_tree() truen \n>    REV_TREE_DIFFERENT if a name decoration _or_ a tree difference exists.\n\nThe incremental diff to do this would be something like the appended.\n\n\t\tLinus\n---\n revision.c |    5 ++++-\n 1 files changed, 4 insertions(+), 1 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex b48e626..1b716c7 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -311,7 +311,10 @@ static int rev_compare_tree(struct rev_info *revs, struct commit *parent, struct\n \tif (revs->simplify_namespace) {\n \t\tstruct name_decoration *name;\n \t\tname = lookup_decoration(&name_decoration, &commit->object);\n-\t\treturn name ? REV_TREE_DIFFERENT : REV_TREE_SAME;\n+\t\tif (name)\n+\t\t\treturn REV_TREE_DIFFERENT;\n+\t\tif (!revs->prune_data)\n+\t\t\treturn REV_TREE_SAME;\n \t}\n \tif (!t2)\n \t\treturn REV_TREE_DIFFERENT;\n"},{"id":"94815","messageId":"adf1fd3d0811031345j4582e109jaf95aede0f33eff7@mail.gmail.com","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031139520.3419@nehalem.linux-foundation.org","subject":"Re: [PATCH 4/4] Add support for 'namespace' history simplification","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-11-03T21:45:16Z","receivedAt":"2008-11-03T21:45:16Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Nov 3, 2008 at 8:43 PM, Linus Torvalds\n<torvalds@linux-foundation.org> wrote:\n>\n> From: Linus Torvalds <torvalds@linux-foundation.org>\n> Date: Mon, 3 Nov 2008 11:25:46 -0800\n> Subject: [PATCH 4/4] Add support for 'namespace' history simplification\n>\n> Maybe this is mis-named, but what it does is to simplify history not by\n> the contents of the tree, but whether a commit has been named (ie it's\n> referred to by some branch or tag) or not.\n\nMaybe --simplify-refs, or --simplify-overview.\n\n>\n> This makes it possible to see the relationship between different named\n> commits, without actually seeing any of the details.\n>\n> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n> ---\n>\n> This is the actual real meat of the logic, and it's really trivial. The\n> actual code is really just a simple\n>\n>    if (simplify-by-namespace)\n>        return lookup_decoration(..) ? REV_TREE_DIFFERENT : REV_TREE_SAME;\n\nI tried it once, but I had problems simplifying the merges, and it is trivial...\n\nNot that it matters a lot, but if you try it on master you get some\nextra merges without a ref like:\n\n373a273 (Merge git-gui 0.11.0, 2008-08-17)\nf44bc33 (Sync with 1.5.6.5, 2008-08-06)\n\nThanks,\nSanti\n"},{"id":"94817","messageId":"alpine.LFD.2.00.0811031358460.3419@nehalem.linux-foundation.org","threadId":"16151","inReplyTo":"adf1fd3d0811031345j4582e109jaf95aede0f33eff7@mail.gmail.com","subject":"Re: [PATCH 4/4] Add support for 'namespace' history simplification","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-11-03T22:05:04Z","receivedAt":"2008-11-03T22:05:04Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 Nov 2008, Santi Béjar wrote:\n> \n> I tried it once, but I had problems simplifying the merges, and it is trivial...\n\nIt depends on the new --simplify-merges code which does that.\n\n> Not that it matters a lot, but if you try it on master you get some\n> extra merges without a ref like:\n> \n> 373a273 (Merge git-gui 0.11.0, 2008-08-17)\n\nUmm? Your point is?\n\nThat merge itself doesn't have a ref, but it's required becase there are \nrefs along both legs of the merge - one side has the \"gitgui-0.11.0\" tag, \nwhile the other has (for example) v16.0-rc3.\n\n> f44bc33 (Sync with 1.5.6.5, 2008-08-06)\n\nAgain, the merge doesn't have a ref, but it's needed because there are \nrefs on both parents (v1.5.6.5 vs v1.6.0-rc[01]).\n\nSo no, --simplify-namespace in no way guarantees that all resulting \ncommits will have refs pointing to them, because it also needs to return \nenough of the merges to make it a real and meaningful DAG.\n\nThe one thing I note is that when you have lots and lots of refs in the \ngitk output, the gitk window itself becomes very ugly. I'd love to get rid \nof the black line between the ref (tag or branch name) and the circle, \nbecause with \"gitk --simplify-namespace\" it ends up looking like some kind \nof insane \"ladder\" due to all those vertical lines.\n\nAnd they really aren't necessary, and it would probably be better to just \nmake selecting a commit highlight the whole row (and thus avoid any \nambiguity between that highlighted commit message and the circle in the \ngraph it goes with if you have a very wide graph).\n\nBut I can't read tcl/tk enough to even figure out where it's being \npainted.\n\n\t\t\tLinus\n"},{"id":"94826","messageId":"200811032328.48632.robin.rosenberg@dewire.com","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031139520.3419@nehalem.linux-foundation.org","subject":"Re: [PATCH 4/4] Add support for 'namespace' history simplification","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2008-11-03T22:28:48Z","receivedAt":"2008-11-03T22:28:48Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"måndag 03 november 2008 20:43:00 skrev Linus Torvalds:\n> \n> From: Linus Torvalds <torvalds@linux-foundation.org>\n> Date: Mon, 3 Nov 2008 11:25:46 -0800\n> Subject: [PATCH 4/4] Add support for 'namespace' history simplification\n> \n> Maybe this is mis-named, but what it does is to simplify history not by\n> the contents of the tree, but whether a commit has been named (ie it's\n> referred to by some branch or tag) or not.\n\nYou could reuse the decoration term here, i.e. --simplify-decorated.\n\n-- robin\n"},{"id":"94821","messageId":"adf1fd3d0811031434w5a74c978q5fbf573288bd9c5a@mail.gmail.com","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031358460.3419@nehalem.linux-foundation.org","subject":"Re: [PATCH 4/4] Add support for 'namespace' history simplification","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-11-03T22:34:19Z","receivedAt":"2008-11-03T22:34:19Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Mon, Nov 3, 2008 at 11:05 PM, Linus Torvalds\n<torvalds@linux-foundation.org> wrote:\n>\n>\n> On Mon, 3 Nov 2008, Santi Béjar wrote:\n>>\n>> I tried it once, but I had problems simplifying the merges, and it is trivial...\n>\n> It depends on the new --simplify-merges code which does that.\n>\n>> Not that it matters a lot, but if you try it on master you get some\n>> extra merges without a ref like:\n>>\n>> 373a273 (Merge git-gui 0.11.0, 2008-08-17)\n>\n> Umm? Your point is?\n>\n> That merge itself doesn't have a ref, but it's required becase there are\n> refs along both legs of the merge - one side has the \"gitgui-0.11.0\" tag,\n> while the other has (for example) v16.0-rc3.\n>\n>> f44bc33 (Sync with 1.5.6.5, 2008-08-06)\n>\n> Again, the merge doesn't have a ref, but it's needed because there are\n> refs on both parents (v1.5.6.5 vs v1.6.0-rc[01]).\n>\n> So no, --simplify-namespace in no way guarantees that all resulting\n> commits will have refs pointing to them, because it also needs to return\n> enough of the merges to make it a real and meaningful DAG.\n\nI thought of it as \"for each ref rewrite its parents to the\nindependent set of refs that are ancestors\". So in the case of 373a273\n(Merge git-gui 0.11.0, 2008-08-17), its parents (gitgui-0.11.0 and\nv1.6.0-rc3) would be the parents of ea02eef (GIT 1.6.0, 2008-08-17).\n\nSanti\n"},{"id":"94875","messageId":"7vzlkfriav.fsf@gitster.siamese.dyndns.org","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031211180.3419@nehalem.linux-foundation.org","subject":"Re: [Q] Abbreviated history graph?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-11-04T08:45:12Z","receivedAt":"2008-11-04T08:45:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> On Mon, 3 Nov 2008, Linus Torvalds wrote:\n>>\n>> I'll post a simple series of four commits in a moment.\n> ...\n> Side note: it's certainly possible that we could improve on this. Right \n> now, \"--simplify-namespace\" will totally override any path simplification, \n> so you can't get a combination of pathnames _and_ naming commits. I don't \n> know exactly what the rules should be, but I could imagine that we could \n> do something like:\n>\n>  - if no pathnames are given, work the way the current patch-series works.\n>\n>  - if path-names are given, make rev_compare_tree() truen \n>    REV_TREE_DIFFERENT if a name decoration _or_ a tree difference exists.\n>\n> Anyway, that's a fairly trivial extension to the idea, and doesn't really \n> matter for the basic code. It can easily be left for later.\n\nThanks.\n\nIncluding this (and the --source one), the series looks reasonable.\n"},{"id":"94921","messageId":"20081104213335.GA19886@localhost","threadId":"16151","inReplyTo":"alpine.LFD.2.00.0811031139520.3419@nehalem.linux-foundation.org","subject":"Re: [PATCH 4/4] Add support for 'namespace' history simplification","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2008-11-04T21:33:35Z","receivedAt":"2008-11-04T21:33:35Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Mon, Nov 03, 2008 at 11:43:00AM -0800, Linus Torvalds wrote:\n> \tgitk --simplify-namespace\n\nVery nice. git log --graph seems to give slightly different results though.\nIn particular, in git.git if I do\n\ngit for-each-ref --format=\"%(refname)\" refs/remotes/origin | \\\nxargs git log --simplify-namespace --graph --pretty='format:%H%n' | \\\ngit name-rev --stdin --name-only | \\\nless\n\nsome of the history is not connected. Is this a known limitation of\ngit log --graph?\n"}]}