Re: [PATCH 2/2] Add a 'source' decorator for commits
On Mon, Oct 27, 2008 at 01:07:10PM -0700, Linus Torvalds wrote:
> We already support decorating commits by tags or branches that point to
> them, but especially when we are looking at multiple branches together,
> we sometimes want to see _how_ we reached a particular commit.
I think this is a cool feature, but I have a few questions/complaints:
- Does it make sense to have this _in addition_ to --decorate (since
for any commit with a --decorate field, it would likely be the same
as --source)? Should it be a different type of decorate instead,
like --decorate=source or --decorate=branch? - Should this be triggered by the "%d" --pretty=format specifier? This
two-liner:diff --git a/pretty.c b/pretty.c
index f6ff312..bdaad19 100644
--- a/pretty.c
+++ b/pretty.c
@@ -487,6 +487,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
const char *prefix = " (";
load_ref_decorations();
+ if (commit->util)
+ printf("%s", (char *)commit->util);
d = lookup_decoration(&name_decoration, &commit->object);
while (d) {
strbuf_addstr(sb, prefix);
works, but:
- it doesn't check revs->show_source, so is it possible that
commit->util is being used for something else?
- using '%d' automatically turns on --decorate, so you end up with
both the --source and --decorate values. More sensible semantics
would be "%d turns on --decorate, unless you have done
--decorate=<explicit format>".
Alternatively, this should just be "%b" or "%S".
- If you don't specify --all, you just get "HEAD" for everything.
Which makes sense when you consider the implementation, but I think
is probably a bit confusing for users.
> Of course, if the commit is reachable through multiple sources (which is
> common), our particular choice of "first" reachable is entirely random
> and depends on the particular path we happened to follow.
Hmm. It would be nice to keep even a simple counter to get a "distance"
from the ref and choose the one with the smallest distance (I think we
can get away without the complex rules that git-describe uses, since we
are not interested in describing the full commit, but rather finding a
"likely" branch).
However, that would require making multiple passes over the commit
graph, which might impact the startup speed.
-Peff
Jeff King <peff@peff.net>