Re: Any objectsions to enhancing git-log to show tags/branch heads?

"Theodore Ts'o" [off-list ref] writes:

I've recently noticed that I'm often firing up gitk for no other purpose
than to see which changesets have which tags and branch heads.  Often
I'll fire up gitk, quickly look at the tags/branches, and then kill it
before it's done parsing the repository, resulting in python errors as
it dies.

So I'm wondering why we haven't arranged to have git-log show this
information, and whether there would be any objections if "git-log"
showed something like this:
...
The only reason why I could imagine not doing this by default would be a
potential performance problem if there were thousands of heads or branch
heads.

I cannot comment on performance impact without knowing exactly
what semantics is being proposed.

 (1) If a commit is not directly pointed by any ref, would it
     get HEAD: or TAG: line, perhaps ala 'git-describe'?

 (2) If a commit is at the tip of two branches, what happens?
     Would it get two HEAD: lines?

 (3) Same question as (2) when a commit is tagged with two tags,
     or at the tip of a branch and pointed by a tag.

As to the impact on people's existing scripts that read git-log,
I think changing --pretty=anything would cause breakage for
somebody.  A new --pretty=format: tag would be the least
destabilizing, but I dunno.

But the fact that you kill gitk before it stops drawing suggests
that you are interested in recent commits only?  What is exactly
the use case?  What I am wondering is:

 (a) you have a handful specific commit IDs and wondering what
     they are, relative to known anchoring points.

     If this is the case, git-describe and git-name-rev may be
     your friend.

 (b) whenever you are browsing random part of history, you often
     wonder which ones are tagged or at the tip.  Browsing "git
     log" output does not give the visual cue of anchoring
     points like "gitk" output does, which annoys you.

     A code-free way to help with this is:

       $ git log | git -p name-rev --stdin

On Mon, Apr 16, 2007 at 10:46:33AM -0700, Junio C Hamano wrote:

I cannot comment on performance impact without knowing exactly
what semantics is being proposed.

 (1) If a commit is not directly pointed by any ref, would it
     get HEAD: or TAG: line, perhaps ala 'git-describe'?

No.

 (2) If a commit is at the tip of two branches, what happens?
     Would it get two HEAD: lines?

Yup, I was assuming it would get two Head: lines, one for each head.

 (3) Same question as (2) when a commit is tagged with two tags,
     or at the tip of a branch and pointed by a tag.

Two tag: lines, one for each tag.  Mercurial's "hg log" does this
today, by the way, and I've found it to be very handy since it makes
it easier to find various tagged releases when browsing the revision
history.

As to the impact on people's existing scripts that read git-log,
I think changing --pretty=anything would cause breakage for
somebody.  A new --pretty=format: tag would be the least
destabilizing, but I dunno.

When I write my shell scripts and parse "Foo: " headers I always
explicitly grep out the headers I want, and assumin a blank line after
the headers, because I expect that future versions might add new
headers, and I want my code to be robust; but I can imagine there
might be some less-than-robust scripts out there....

But the fact that you kill gitk before it stops drawing suggests
that you are interested in recent commits only?  What is exactly the
use case?

Well, usually what I'm interested in is near the tip, but not always.
In general, seeing the anchor points is part of the problem, and so
"git log | git -p name-rev --stdin" is useful, although it isn't as
useful as "gitk" when a revision has multiple HEAD or TAG's associated
with it, and git-name-rev doesn't know which one(s) would be of
greatest interest.

						- Ted