{"thread":{"id":"16066","subject":"[PATCH 0/2] Random patches from my tree","startedAt":"2008-10-27T20:05:45Z","lastAt":"2008-10-28T20:27:03Z","messageCount":14,"participants":["Linus Torvalds","Jeff King","Pierre Habouzit"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"94075","messageId":"alpine.LFD.2.00.0810271256470.3386@nehalem.linux-foundation.org","threadId":"16066","inReplyTo":null,"subject":"[PATCH 0/2] Random patches from my tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-27T20:05:45Z","receivedAt":"2008-10-27T20:05:45Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOk, here's two random patches that I have in my git tree that may or may \nnot be interesting.\n\nThe first one is something I did a long time ago because I was irritated \nby the \"skipping inexact rename detection\" message not really telling me \n_why_ it did so - just \"too many files\". So it just adds the information \nabout number of deleted and created files.\n\nThe second one was something I whipped up due to the discussion about \n\"which branch is a commit from\". It adds a \"--source\" flag to the log \ncommand family, which then makes the revision walker save off the name of \nthe commit in the '->util' field, and makes 'show_decorations()' show it.\n\nSo the second one allows things like\n\n\tgit log --pretty=oneline --source --all\n\nand it gives a somewhat useful view of which branch some commit came in \non, by just showing _which_ of the references was the one that reached \na particular commit first.\n\nOf course, with commits that are reached multiple ways the whole notion of \n\"which one reached us\" is ambiguous, and it just picks one rather than \nbuilding up any list of them. The first name we reach somethign through \nis the one that a commit sticks with. That's generally what you want.\n\nI guess we should have a \"--pretty=format\" thing for it too, and maybe you \nwant to support it for 'git rev-list' as well, but that's for others to \ndecide - it people think it's useful.\n\n\t\t\tLinus\n"},{"id":"94076","messageId":"alpine.LFD.2.00.0810271305500.3386@nehalem.linux-foundation.org","threadId":"16066","inReplyTo":"alpine.LFD.2.00.0810271256470.3386@nehalem.linux-foundation.org","subject":"[PATCH 1/2] Add file delete/create info when we overflow rename_limit","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-27T20:06:16Z","receivedAt":"2008-10-27T20:06:16Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nWhen we refuse to do rename detection due to having too many files\ncreated or deleted, let the user know the numbers.  That way there is a\nreasonable starting point for setting the diff.renamelimit option.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n diffcore-rename.c |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/diffcore-rename.c b/diffcore-rename.c\nindex 1b2ebb4..168a95b 100644\n--- a/diffcore-rename.c\n+++ b/diffcore-rename.c\n@@ -493,7 +493,7 @@ void diffcore_rename(struct diff_options *options)\n \tif ((num_create > rename_limit && num_src > rename_limit) ||\n \t    (num_create * num_src > rename_limit * rename_limit)) {\n \t\tif (options->warn_on_too_large_rename)\n-\t\t\twarning(\"too many files, skipping inexact rename detection\");\n+\t\t\twarning(\"too many files (created: %d deleted: %d), skipping inexact rename detection\", num_create, num_src);\n \t\tgoto cleanup;\n \t}\n \n-- \n1.6.0.3.517.g759a.dirty\n"},{"id":"94077","messageId":"alpine.LFD.2.00.0810271306230.3386@nehalem.linux-foundation.org","threadId":"16066","inReplyTo":"alpine.LFD.2.00.0810271305500.3386@nehalem.linux-foundation.org","subject":"[PATCH 2/2] Add a 'source' decorator for commits","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-27T20:07:10Z","receivedAt":"2008-10-27T20:07:10Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\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 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.517.g759a.dirty\n"},{"id":"94080","messageId":"alpine.LFD.2.00.0810271328310.3386@nehalem.linux-foundation.org","threadId":"16066","inReplyTo":"alpine.LFD.2.00.0810271256470.3386@nehalem.linux-foundation.org","subject":"Re: [PATCH 0/2] Random patches from my tree","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-27T20:37:22Z","receivedAt":"2008-10-27T20:37:22Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOn Mon, 27 Oct 2008, Linus Torvalds wrote:\n> \n> So the second one allows things like\n> \n> \tgit log --pretty=oneline --source --all\n\nA better example may have --abbrev-commit, at which point my current git \ntree looks like this for me:\n\n\t52be8b3... refs/heads/master Add a 'source' decorator for commits\n\taffba33... refs/heads/master Add file delete/create info when we overflow rename\n\t6806f78... refs/remotes/origin/pu Merge branch 'ar/mksnpath' into pu\n\t058412d... refs/remotes/origin/pu Fix potentially dangerous uses of mkpath and g\n\t356af64... refs/remotes/origin/pu Merge branch 'ar/maint-mksnpath' into HEAD\n\t9fa03c1... refs/remotes/origin/pu Fix potentially dangerous uses of mkpath and g\n\t94cc355... refs/remotes/origin/pu Fix mkpath abuse in dwim_ref and dwim_log of s\n\t108bebe... refs/remotes/origin/pu Add mksnpath which allows you to specify the o\n\t6af1fc2... refs/remotes/origin/man Autogenerated manpages for v1.6.0.3-523-g304d\n\t61b1229... refs/remotes/origin/html Autogenerated HTML docs for v1.6.0.3-523-g30\n\tf3ce133... refs/remotes/origin/pu Merge branch 'jc/send-pack-tell-me-more' into \n\t2b37e3a... refs/remotes/origin/pu Merge branch 'jk/renamelimit' into pu\n\t..\n\nie you can see the the branch that the commits are on.\n\nAn example of the ambiguous nature would be \n\n\t304d058... refs/remotes/origin/HEAD Merge branch 'maint'\n\nie because the HEAD and 'master' branches of refs/remotes/origin are the \nsame, it's ambiguous which one to take, and git will have picked one at \nrandom. And obviously when you hit a point where two branches meet again, \nit really will depend on which branch we happened to be parsing at the \ntime (which generally is \"which branch had a commit date that was further \nback in history\").\n\nAnother known deficiency: \"gitk --source\" doesn't work (neither does \"gitk \n--decorate\" for that matter). gitk gets very upset indeed if you try, and \nsucks up CPU cycles in some infinite loop.\n\n\n\t\tLinus\n"},{"id":"94092","messageId":"20081028054539.GA23195@sigill.intra.peff.net","threadId":"16066","inReplyTo":"alpine.LFD.2.00.0810271306230.3386@nehalem.linux-foundation.org","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-28T05:45:40Z","receivedAt":"2008-10-28T05:45:40Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 27, 2008 at 01:07:10PM -0700, Linus Torvalds wrote:\n\n> We already support decorating commits by tags or branches that point to\n> them, but especially when we are looking at multiple branches together,\n> we sometimes want to see _how_ we reached a particular commit.\n\nI think this is a cool feature, but I have a few questions/complaints:\n\n  - Does it make sense to have this _in addition_ to --decorate (since\n    for any commit with a --decorate field, it would likely be the same\n    as --source)? Should it be a different type of decorate instead,\n    like --decorate=source or --decorate=branch?\n\n  - Should this be triggered by the \"%d\" --pretty=format specifier? This\n    two-liner:\n\ndiff --git a/pretty.c b/pretty.c\nindex f6ff312..bdaad19 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -487,6 +487,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)\n \tconst char *prefix = \" (\";\n \n \tload_ref_decorations();\n+\tif (commit->util)\n+\t\tprintf(\"%s\", (char *)commit->util);\n \td = lookup_decoration(&name_decoration, &commit->object);\n \twhile (d) {\n \t\tstrbuf_addstr(sb, prefix);\n\n    works, but:\n\n      - it doesn't check revs->show_source, so is it possible that\n        commit->util is being used for something else?\n\n      - using '%d' automatically turns on --decorate, so you end up with\n        both the --source and --decorate values. More sensible semantics\n        would be \"%d turns on --decorate, unless you have done\n        --decorate=<explicit format>\".\n\n        Alternatively, this should just be \"%b\" or \"%S\".\n\n  - If you don't specify --all, you just get \"HEAD\" for everything.\n    Which makes sense when you consider the implementation, but I think\n    is probably a bit confusing for users.\n\n> Of course, if the commit is reachable through multiple sources (which is\n> common), our particular choice of \"first\" reachable is entirely random\n> and depends on the particular path we happened to follow.\n\nHmm. It would be nice to keep even a simple counter to get a \"distance\"\nfrom the ref and choose the one with the smallest distance (I think we\ncan get away without the complex rules that git-describe uses, since we\nare not interested in describing the full commit, but rather finding a\n\"likely\" branch).\n\nHowever, that would require making multiple passes over the commit\ngraph, which might impact the startup speed.\n\n-Peff\n"},{"id":"94104","messageId":"20081028131116.GA8272@artemis.googlewifi.com","threadId":"16066","inReplyTo":"20081028054539.GA23195@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-28T13:11:16Z","receivedAt":"2008-10-28T13:11:16Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Oct 28, 2008 at 05:45:40AM +0000, Jeff King wrote:\n> On Mon, Oct 27, 2008 at 01:07:10PM -0700, Linus Torvalds wrote:\n> > Of course, if the commit is reachable through multiple sources (which is\n> > common), our particular choice of \"first\" reachable is entirely random\n> > and depends on the particular path we happened to follow.\n> \n> Hmm. It would be nice to keep even a simple counter to get a \"distance\"\n> from the ref and choose the one with the smallest distance (I think we\n> can get away without the complex rules that git-describe uses, since we\n> are not interested in describing the full commit, but rather finding a\n> \"likely\" branch).\n> \n> However, that would require making multiple passes over the commit\n> graph, which might impact the startup speed.\n\nActually I tried to do that (and you meant name-rev --contains rather\nthan describe actually ;p), and I stopped because it's too slow. I\nbelieve the proper way to do that is to help git-log knowing which are\nthe short (topic) branches, and to crawl incrementally using a\ndate-based hack. This would basically work a bit like this. Let's\nimaging you want to crawl \"next\" in git and know which topics from pu\nare in it. You would say e.g.:\n\ngit-log --topics=*/* next (as pretty much every */* is a topic branch\nfor git.git).\n\n\nThen one has to know which are the heads of every topic branches first,\nthen crawl next the usual way, except that when you arrive to a point\nthat is a topic branch head, you don't look that way. You remember the\ndate of that point, and continue to crawl \"next\" a bit further so that\nyou can start annotating the topic's commits you've stumbled upon. And\nyou do that, you look at jd/topic (as in John Doe topic branch) and mark\nall the commits as being from jd/topic, until you either go back to some\ncommit from next, or your current commit date is younger than your\ncurrent \"next\" crawling front. In the former case, you're done with that\ntopic, in the latter you must continue to preprocess \"next\" a bit more.\n\nThat should allow incremental output, FSVO incremental (in the git.git\nkind of integration, you have buckets of topic branches merges, and\nbasically we would have output being spit bucket per bucket I believe).\n\n\nIf you do that, you don't really need to keep distance scores, this\nshould, I believe, yield decent enough results, while being incremental,\nwhich should yield almost instantaneous output.\n\nPoint is, I've no clue how to do that with our crawling primitives right\nnow, to be fair, I didn't looked at it because I'm lazy and don't have\nenough topic branches to work with in my projects, so it's not an itch\nyet ;)\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"94105","messageId":"20081028131928.GB8272@artemis.googlewifi.com","threadId":"16066","inReplyTo":"20081028131116.GA8272@artemis.googlewifi.com","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-28T13:19:28Z","receivedAt":"2008-10-28T13:19:28Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Oct 28, 2008 at 01:11:16PM +0000, Pierre Habouzit wrote:\n> On Tue, Oct 28, 2008 at 05:45:40AM +0000, Jeff King wrote:\n> > On Mon, Oct 27, 2008 at 01:07:10PM -0700, Linus Torvalds wrote:\n> > > Of course, if the commit is reachable through multiple sources (which is\n> > > common), our particular choice of \"first\" reachable is entirely random\n> > > and depends on the particular path we happened to follow.\n> > \n> > Hmm. It would be nice to keep even a simple counter to get a \"distance\"\n> > from the ref and choose the one with the smallest distance (I think we\n> > can get away without the complex rules that git-describe uses, since we\n> > are not interested in describing the full commit, but rather finding a\n> > \"likely\" branch).\n> > \n> > However, that would require making multiple passes over the commit\n> > graph, which might impact the startup speed.\n> \n> Actually I tried to do that (and you meant name-rev --contains rather\n> than describe actually ;p), and I stopped because it's too slow. I\n> believe the proper way to do that is to help git-log knowing which are\n> the short (topic) branches, and to crawl incrementally using a\n> date-based hack. This would basically work a bit like this. Let's\n> imaging you want to crawl \"next\" in git and know which topics from pu\n> are in it. You would say e.g.:\n> \n> git-log --topics=*/* next (as pretty much every */* is a topic branch\n> for git.git).\n> \n> \n> Then one has to know which are the heads of every topic branches first,\n> then crawl next the usual way, except that when you arrive to a point\n> that is a topic branch head, you don't look that way. You remember the\n> date of that point, and continue to crawl \"next\" a bit further so that\n> you can start annotating the topic's commits you've stumbled upon. And\n> you do that, you look at jd/topic (as in John Doe topic branch) and mark\n> all the commits as being from jd/topic, until you either go back to some\n> commit from next, or your current commit date is younger than your\n> current \"next\" crawling front. In the former case, you're done with that\n> topic, in the latter you must continue to preprocess \"next\" a bit more.\n\nMy description is clumsy, as we probably sometimes want to crawl topics\nthat aren't merged either like in git-log --topics=*/* --all.  But we\njust have to mark the current \"front\" of the walk, and have it sorted\nbetween things that are part of topic heads and the thing that are not.\nWe don't even need to decorate the things that are _not_ part of the\ntopics at all I'd say, because that's where you definitely need distance\nbased algorithms and multiple passes to yield correct results.\n\nWhereas for the specific case of topic branches, which is what people\nwant (see Ingo's mails on the subject a week or so ago), the algorithm I\npropose is, I guess, mostly O(n + m) in the number of walked commits (n)\nand references (m). IOW fast.\n\n\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"94113","messageId":"alpine.LFD.2.00.0810280755570.3386@nehalem.linux-foundation.org","threadId":"16066","inReplyTo":"20081028054539.GA23195@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-28T15:17:02Z","receivedAt":"2008-10-28T15:17:02Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Oct 2008, Jeff King wrote:\n> \n>   - Does it make sense to have this _in addition_ to --decorate (since\n>     for any commit with a --decorate field, it would likely be the same\n>     as --source)? Should it be a different type of decorate instead,\n>     like --decorate=source or --decorate=branch?\n\nI think they are different. People who want --source generally have other \nissues than people who want --decorate, and the two do actually work \ntogether.\n\nIn particular, think about things like \"gitk\", which currently can't do \n_either_, but that could easily support both. Even to the point where gitk \nmight want to add both flags on its own, just to always get the branch and \nthe decorate output.\n\nAnd no, they are _not_ the same. They are vehemently not the same when you \nuse abything but '--all', and even with --all they are different because \ndecorate has no problems with multiple decorations on one commit, while \nsource is very much a single thing per commit.\n\nAnd --source really has to be just a single data field, because anything \nelse will almost inevitably be too expensive to be worth it.\n\n\n>   - Should this be triggered by the \"%d\" --pretty=format specifier? This\n>     two-liner:\n> \n> diff --git a/pretty.c b/pretty.c\n> index f6ff312..bdaad19 100644\n> --- a/pretty.c\n> +++ b/pretty.c\n> @@ -487,6 +487,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)\n>  \tconst char *prefix = \" (\";\n>  \n>  \tload_ref_decorations();\n> +\tif (commit->util)\n> +\t\tprintf(\"%s\", (char *)commit->util);\n>  \td = lookup_decoration(&name_decoration, &commit->object);\n>  \twhile (d) {\n>  \t\tstrbuf_addstr(sb, prefix);\n> \n>     works, but:\n> \n>       - it doesn't check revs->show_source, so is it possible that\n>         commit->util is being used for something else?\n\nIndeed. You should always do the show_source check. There are different \nthings that use 'util', and while I don't think any of them will ever use \nthe format string, it's still a good idea to just make it consistent.\n\nHowever:\n\n>       - using '%d' automatically turns on --decorate, so you end up with\n>         both the --source and --decorate values. More sensible semantics\n>         would be \"%d turns on --decorate, unless you have done\n>         --decorate=<explicit format>\".\n\nAs mentioned above, I think this is a non-starter. I don't think \n\"decorate\" and \"source\" really have anything to do with each other, except \nthat they get printed out in similar ways and in the same function for the \ndefault printout.\n\nAnd quite frankly, even that was partly just a \"minimal diff\" thing, \nalthough I do think that they both are \"decorations\", it's just that they \nare very _different_ decorations.\n\n>         Alternatively, this should just be \"%b\" or \"%S\".\n\nSo yeah, I'd expect a new format specifier.\n\n>   - If you don't specify --all, you just get \"HEAD\" for everything.\n>     Which makes sense when you consider the implementation, but I think\n>     is probably a bit confusing for users.\n\nI don't think it's at all confusing, for two reasons:\n\n - you'd never ever use it manually unless you give multiple branches. Why \n   would you spend time to type out '--source' unless it was because you \n   needed to?\n\n - for scripting, you want things consistent, even if the 'consistency' is \n   purely about always showing HEAD when that's the only source.\n\nFor the second case, imagine having gitk always add \"--source\" and \n\"--decorate\" to the command line (the same way it always adds --parents \nand --pretty=raw etc). gitk doesn't want to care how many branches you \ngive it as arguments, or whether you use --tags or --all. But it would \nwant to always parse things the same way.\n\nNo?\n\n> Hmm. It would be nice to keep even a simple counter to get a \"distance\"\n> from the ref and choose the one with the smallest distance\n\nWe don't have the space. The other fields on \"struct commit\" are already \nused (indegree is used for topo sorting etc), and while we could make the \npointer itself point to a more complex structure rather than the name (one \nthat contains counts and possibly multiple names), that would now mean \nthat we'd have to make another allocation for each commit. \n\nAnd that's very much against the whole point of the 'source' decoration. \nIt was designed to be basically zero-cost. \n\nI could imagine doing it as not a single string: you could make it be a \npointer to a list of (alphabetically sorted) strings, and then you don't \nhave to make an allocation for each commit, you'd only need to do \nsomething like\n\n\tvoid add_source(struct commit *commit, struct strin_list *list)\n\t{\n\t\tstruct string_list *old = commit->util;\n\n\t\tif (!old) {\n\t\t\tcommit->util = list;\n\t\t\treturn;\n\t\t}\n\t\tif (old == list)\n\t\t\treturn;\n\t\t.. do a union sort of 'old'/'list' ..\n\t}\n\nand I think it would be a stable algorithm (ie we'd share all normal \ncases, and only have to allocate new lists in the relatively rare cases of \ngraphs joining), and that would be acceptable.\n\nBut the \"counter\" thing would not work. Not because it's expensive to \ncount (it's not - you just increment the counter every time you go to a \nparent, and then if the parent already has a ->util entry, you replace it \nif the new one has a smaller count), but because it's just expensive to do \nanother allocation for each commit.\n\n(Of course, \"expense\" is relative. Maybe another allocation is ok, since \nit would only trigger with --source.)\n\n\t\tLinus\n"},{"id":"94122","messageId":"alpine.LFD.2.00.0810281016150.3386@nehalem.linux-foundation.org","threadId":"16066","inReplyTo":"alpine.LFD.2.00.0810280755570.3386@nehalem.linux-foundation.org","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-10-28T17:21:39Z","receivedAt":"2008-10-28T17:21:39Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 28 Oct 2008, Linus Torvalds wrote:\n> \n> I could imagine doing it as not a single string: you could make it be a \n> pointer to a list of (alphabetically sorted) strings, and then you don't \n> have to make an allocation for each commit, you'd only need to do \n> something like\n> \n> \tvoid add_source(struct commit *commit, struct strin_list *list)\n\nActually, no. That would be wrong.\n\nWhy? Becuase we might be printing out the commit before we see it for the \nsecond time, so if we were to print out anything but the \"first reached \ndata\", we'd now have really nasty _unreliable_ data that would actually \nchange depending on whether we also do things like --topo-sort and/or do \ncommit limiting.\n\nSo suddenly --source would have to do the full tree just to make sure that \nit's reliably giving the same information, and that makes it much less \nuseful.\n\nIn contrast, the thing I sent out is not only really simple and has \nbasically zero peformance impact, but it's actually \"more reliable\" in \nthat what it gives you is meaningful and clear. It might pick one \nparticular name over another in random ways that depend on internal \nchoices and the exact order that you gave your arguments in, but it \ndoesn't even _try_ to claim anything else.\n\nThe source \"name\" is unambiguous only if there is a single source, and it \ndoesn't really even try to claim anything else - for other cases, it will \ngive answers that \"make sense\" but they won't necessarily be the _whole_ \ntruth. But it won't ever be really misleading either, and it will never \ncause any slowdowns.\n\n\t\tLinus\n"},{"id":"94129","messageId":"20081028192942.GA752@sigill.intra.peff.net","threadId":"16066","inReplyTo":"alpine.LFD.2.00.0810280755570.3386@nehalem.linux-foundation.org","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-28T19:29:43Z","receivedAt":"2008-10-28T19:29:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 28, 2008 at 08:17:02AM -0700, Linus Torvalds wrote:\n\n> >   - Does it make sense to have this _in addition_ to --decorate (since\n> >     for any commit with a --decorate field, it would likely be the same\n> >     as --source)? Should it be a different type of decorate instead,\n> >     like --decorate=source or --decorate=branch?\n> \n> I think they are different. People who want --source generally have other \n> issues than people who want --decorate, and the two do actually work \n> together.\n\nSleeping on this and thinking about it some more, I think you are right\nhere, and all of the other complaints I had just go away.\n\nI was thinking of it as \"decorate commits with the likely branches they\nwere made on.\" But that's not what this is at all (though it happens to\ncome up with similar answers!). It's really about \"show which ref, of\nthe refs which were requested to be shown, we started at to reach this\ncommit.\" Which is perhaps more limited, but obvoiusly is much faster to\ncompute.\n\nAnd then the output of \"git log --source HEAD\" makes perfect sense, and\nit makes sense not to worry about finding the \"closest\" ref. It is\nreally about annotating the traversal that you asked for.\n\nSo now my only complaint is the lack of documentation and tests. ;)\n\n-Peff\n"},{"id":"94133","messageId":"20081028194642.GB752@sigill.intra.peff.net","threadId":"16066","inReplyTo":"20081028131116.GA8272@artemis.googlewifi.com","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-28T19:46:43Z","receivedAt":"2008-10-28T19:46:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 28, 2008 at 02:11:16PM +0100, Pierre Habouzit wrote:\n\n> Actually I tried to do that (and you meant name-rev --contains rather\n> than describe actually ;p), and I stopped because it's too slow. I\n\nI think we are both wrong, since it's \"git describe --contains\". ;)\nBut yes, that was what I meant.\n\n> believe the proper way to do that is to help git-log knowing which are\n> the short (topic) branches, and to crawl incrementally using a\n> date-based hack. This would basically work a bit like this. Let's\n> imaging you want to crawl \"next\" in git and know which topics from pu\n> are in it. You would say e.g.:\n\nHmm. Why a date-based hack to see what's on the topic branch? Why not\njust give an option to walk the graph twice, giving name-rev style\nannotations, and just let it be slow. People will mostly look at it by\nspecifying just their topic branches anyway. IOW:\n\n  git log ^origin/master my/topic1 my/topic2 my/topic3\n\nand by virtue of the fact that you are vastly limiting the size of the\ntree, it won't actually end up too slow. So you haven't said so much\n\"these are my topic branches\" as \"I am just not interested in things\nthat are already upstream.\"\n\nOr maybe I'm misunderstanding something here:\n\n> Then one has to know which are the heads of every topic branches first,\n> then crawl next the usual way, except that when you arrive to a point\n> that is a topic branch head, you don't look that way. You remember the\n> date of that point, and continue to crawl \"next\" a bit further so that\n> you can start annotating the topic's commits you've stumbled upon. And\n> you do that, you look at jd/topic (as in John Doe topic branch) and mark\n> all the commits as being from jd/topic, until you either go back to some\n> commit from next, or your current commit date is younger than your\n> current \"next\" crawling front. In the former case, you're done with that\n> topic, in the latter you must continue to preprocess \"next\" a bit more.\n\nWhen you say \"heads of topic branches\" do you mean we actually have the\ntopic branches? Or do you mean you want to crawl next, pulling the names\nof the topic branches from the merge messages?\n\n-Peff\n"},{"id":"94134","messageId":"20081028195304.GC752@sigill.intra.peff.net","threadId":"16066","inReplyTo":"20081028194642.GB752@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-28T19:53:04Z","receivedAt":"2008-10-28T19:53:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 28, 2008 at 03:46:43PM -0400, Jeff King wrote:\n\n> \n> Hmm. Why a date-based hack to see what's on the topic branch? Why not\n> just give an option to walk the graph twice, giving name-rev style\n> annotations, and just let it be slow. People will mostly look at it by\n> specifying just their topic branches anyway. IOW:\n> \n>   git log ^origin/master my/topic1 my/topic2 my/topic3\n\nAnd obviously you could split the \"these are the commits to annotate\"\nspecification from \"these are the commits to show\". But I actually think\nin practice most users would want those to be the same.\n\n-Peff\n"},{"id":"94135","messageId":"20081028200901.GA2894@artemis.mtv.corp.google.com","threadId":"16066","inReplyTo":"20081028194642.GB752@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2008-10-28T20:09:02Z","receivedAt":"2008-10-28T20:09:02Z","isPatch":true,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Tue, Oct 28, 2008 at 07:46:43PM +0000, Jeff King wrote:\n> On Tue, Oct 28, 2008 at 02:11:16PM +0100, Pierre Habouzit wrote:\n> > believe the proper way to do that is to help git-log knowing which are\n> > the short (topic) branches, and to crawl incrementally using a\n> > date-based hack. This would basically work a bit like this. Let's\n> > imaging you want to crawl \"next\" in git and know which topics from pu\n> > are in it. You would say e.g.:\n> \n> Hmm. Why a date-based hack to see what's on the topic branch? Why not\n> just give an option to walk the graph twice,\n\nit serves the purpose to not walk the graph twice actually, but indeed\ntwice is not _that_ bad.\n \n> giving name-rev style annotations, and just let it be slow. People\n> will mostly look at it by specifying just their topic branches anyway.\n> IOW:\n> \n>   git log ^origin/master my/topic1 my/topic2 my/topic3\n> \n> and by virtue of the fact that you are vastly limiting the size of the\n> tree, it won't actually end up too slow. So you haven't said so much\n> \"these are my topic branches\" as \"I am just not interested in things\n> that are already upstream.\"\n\nWell, I was just thinking quickly during jetlag-induced insomnia. I\ndon't really care about the issue that much actually.\n-- \n·O·  Pierre Habouzit\n··O                                                madcoder@debian.org\nOOO                                                http://www.madism.org\n"},{"id":"94136","messageId":"20081028202702.GA1876@sigill.intra.peff.net","threadId":"16066","inReplyTo":"20081028200901.GA2894@artemis.mtv.corp.google.com","subject":"Re: [PATCH 2/2] Add a 'source' decorator for commits","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-28T20:27:03Z","receivedAt":"2008-10-28T20:27:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Oct 28, 2008 at 09:09:02PM +0100, Pierre Habouzit wrote:\n\n> > Hmm. Why a date-based hack to see what's on the topic branch? Why not\n> > just give an option to walk the graph twice,\n> \n> it serves the purpose to not walk the graph twice actually, but indeed\n> twice is not _that_ bad.\n\nSure, and that is reasonable. But I think the real goal is \"give this\ninformation in a not-painfully slow manner\". So if we can do it by\nwalking a smaller graph twice, I think that is OK, too.\n\n> Well, I was just thinking quickly during jetlag-induced insomnia. I\n> don't really care about the issue that much actually.\n\nHeh. I have to admit I don't care enough to work on this personally,\neither. I just _thought_ Linus was working on it, but I think what he is\ndoing is subtly different, and our discussion has diverged to something\nthat, if it ever came to pass, would be a separate feature.\n\n-Peff\n"}]}