Jeff King <peff@xxxxxxxx> writes: > On Mon, Mar 08, 2010 at 01:20:32AM -0800, Junio C Hamano wrote: > >> 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: >> [...] >> 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. > > True, but turning off configured decorations also helps scripts. I think > we can all agree that normal "git log" is not supposed to be consumed by > scripts, but should "git log --pretty=raw" turn off configured > decorations? > > With the current code, gitk (which calls "log --pretty=raw") barfs on a > repository with log.decorate turned on. Yuck. Do you mean we would need _at least_ something like this? I am undecided if we should limit to FMT_RAW if that is the case, though. Reading from "git log --pretty=raw" is just as unkosher as reading from "git log --pretty=oneline", but a bigger question is do we still have enough plumbing support to replace them, or Porcelain "log" has advanced too much too quickly, leaving plumbing "rev-list" behind. I can obviously rip the configuration variable support out. Steven, what do you want to do? builtin-log.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/builtin-log.c b/builtin-log.c index 0afba31..29a59b0 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -77,6 +77,8 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix, if (!rev->show_notes_given && !rev->pretty_given) rev->show_notes = 1; + if (rev->pretty_given && rev->commit_format == CMIT_FMT_RAW) + decoration_style = 0; if (rev->diffopt.pickaxe || rev->diffopt.filter) rev->always_show_header = 0; -- 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