Re: [PATCH 3/4] --decorate now decorates ancestors, too

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 12, 2007, 18:45 UTC
Message-ID: <7vmyy1tq96.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070711022714.GI27033@thunk.org>

Theodore Tso <tytso@mit.edu> writes:

Show 18 quoted lines

> On Wed, Jul 11, 2007 at 02:29:49AM +0100, Johannes Schindelin wrote:
>> 
>> The option --decorate changed default behavior: Earlier, it decorated
>> commits pointed to by any ref.  The new behavior is this: decorate the
>> with the given refs and its ancestors, i.e.
>> 
>> 	git log --decorate next master
>> 
>> will show "next", "next^", "next~2", ..., "master", "master^", ...
>> in parenthesis after the commit name.
>
> I'm wondering how useful the default is.  The arguments get used for
> two things; both for git-log to decide what revisions to display, and
> which refs to decorate, right?  I'm not sure that overloading is such
> a great idea.
>
> Also, I note that "git log --decorate" does nothing at all.  Maybe it
> would be better to keep the default to be "any-ref" instead of "given"?

I think defaulting to "given" is a regression. It could be argued that "tag-ref" or "tag" might be a better default (judging from my experience with "name-rev"), but keeping "any-ref" would probably be the safest.

But in general I do not see ("I haven't realized" might turn out to be a better expression) much value in this series yet except for the initial clean-up patches, while I think this option would be quite expensive in terms of memory footprints on projects with nontrivial size of history. I dunno.