Hi,
On Thu, 12 Jul 2007, Junio C Hamano wrote:
> Theodore Tso <tytso@xxxxxxx> writes:
>
> > 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.
Okay, fair enough. I kind of expected people to disagree as of the
default mode. My preference would have been "tag", since I need that
quite often, but I am willing to put my wishes aside there.
Probably I should follow up with a replacement patch, and a config
variable "commit.decorateMode" patch, leaving the default at "any-ref"?
> 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.
There are a few points I want to make to convince you:
- I need this quite often to see which version introduced a certain
feature. This is most visible on IRC, where people ask "how can I do X,
I have version Y", and me responding "There is a feature P, but
unfortunately, it is only available from revision Q~N" where Q > Y.
I really want other people to do this easily, without having to know how
name-rev (which has a dash in its name, and thus is kind of
plumbing-ish) works.
- It is _not_ expensive. It only ever allocates something in the case of
merges (at least that's how I designed it), and should free the used
memory when the commit name is not used at all (but maybe I forgot that
part...). So you will have at most one allocation of a few bytes per
merge, and I really do not see how this could break down for
pathological, but real-world, cases.
- 40-character commit names seem to be really hard on people.
To drive the 3rd point home: I often see people confused as to what those
long commit names are. They do not even realise that they are _object_
names, actually, not only applicable to commit objects.
IMHO a great way to teach users that commit names are equivalent to
shortcuts like "v1.5.0-rc1~20" would be to even enable decoration by tags
by default.
Ciao,
Dscho
-
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
