Junio C Hamano <gitster@xxxxxxxxx> writes:
> [Stalled]
>
> * sd/log-decorate (2010-02-17) 3 commits
> - log.decorate: usability fixes
> - Add `log.decorate' configuration variable.
> - git_config_maybe_bool()
>
> Probably ready for 'next', except that people need to be warned about
> having to update their scripts to explicitly pass --no-decorate to keep
> them working. A good idea to disable this when --pretty was given, just
> like notes are disabled by default, was floated.
After thinking about this a bit more, I do not think it is a good idea to
disable configured decoration when an explicit --pretty is given. A patch
to do so would be a trivial two-liner:
diff --git a/builtin-log.c b/builtin-log.c
index 0afba31..d4090f1 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -85,6 +85,10 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
if (rev->diffopt.nr_paths != 1)
usage("git logs can only follow renames on one pathname at a time");
}
+
+ if (rev->pretty_given)
+ decoration_style = 0;
+
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (!strcmp(arg, "--decorate")) {
but there is one big difference between notes and decoration. Decorations
are designed to be a small, one-per-ref tokens that would sit well on a
line that already has other essential informations, while notes are a lot
louder "in your face" annotations that occupy line(s) on their own.
So I think we are better off without the above patch. Unless somebody
points out flaws in my thinking, I am planning to merge this to 'next'
shortly.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html