The space between the commit and the source attribute is not easily machine-parseable: if we combine --source with --parents and give a SHA1 as a starting point, it's unnecessarily hard to see where the list of parents ends and the source decoration begins.
Example: git show --parents --source $(git rev-list HEAD)
which is admittedly contrived, but can easily happen in scripting.
So use a <tab> instead of a space as the source separator.
The other decorations didn't have this issue, because they were surrounded by parenthesis, so it's obvious that they aren't parent SHA1's.
It so happens that _visually_ this makes no difference for "git log --source", since "commit <40-char SHA1>" is 47 characters, so both a space and a <tab> will end up showing as a single commit. Of course, with '--pretty=oneline' or '--parents' or '--abbrev-commit' you'll see the difference.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> ---
This is all partly because I also wish that 'gitk' would use --decorate to give decorations rather than look them up by hand. I'm not entirely source --source is useful for gitk (since it wants _all_ branches), but I do know that I hate knowing that
gitk --source
just results in parse errors.
log-tree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c index 5444f08..194ddb1 100644 --- a/log-tree.c +++ b/log-tree.c @@ -58,7 +58,7 @@ void show_decorations(struct rev_info *opt, struct commit *commit) struct name_decoration *decoration; if (opt->show_source && commit->util) - printf(" %s", (char *) commit->util); + printf("\t%s", (char *) commit->util); if (!opt->show_decorations) return; decoration = lookup_decoration(&name_decoration, &commit->object);