Thread (11 messages) flat view 11 messages, 3 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:21

Theodore Tso [off-list ref] writes:
On Wed, Jul 11, 2007 at 02:29:49AM +0100, Johannes Schindelin wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help