threads / discuss / 7677

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

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

## tl;dr

15 messages between Apr 16, 2007 and Apr 23, 2007.

replies: 14people: 8as markdown or json

Theodore Ts'o· Apr 16, 2007, 12:45 UTC · lore

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:

commit 7d5021d2ef5d414908d8e4db26c324c1de19f9f1
Head: tytso-patches-20070223
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Fri Feb 23 14:46:01 2007 -0500
Cherry pick "unload head on shutdown" patch
...
commit c8f71b01a50597e298dc3214a2f2be7b8d31170c
Tag: v2.6.21-rc1
Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
Date:   Tue Feb 20 20:32:30 2007 -0800
    Linux 2.6.21-rc1

Would there be objections in adding this to --pretty=medium (i.e., the default), or would it be better to add something like tihs to --pretty=full or --pretty=fuller?

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.

						- Ted
Junio C Hamano· Apr 16, 2007, 17:46 UTC · re: Theodore Ts'o · lore

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

"Theodore Ts'o" <tytso@mit.edu> writes:
Show 13 quoted lines
> 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
Theodore Tso· Apr 16, 2007, 20:46 UTC · re: Junio C Hamano · lore

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

On Mon, Apr 16, 2007 at 10:46:33AM -0700, Junio C Hamano wrote:
Show 5 quoted lines
> 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
Peter Baumann· Apr 16, 2007, 18:13 UTC · re: Theodore Ts'o · lore

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

On Mon, Apr 16, 2007 at 08:45:55AM -0400, Theodore Ts'o wrote:
Show 36 quoted lines
> 
> 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:
> 
> commit 7d5021d2ef5d414908d8e4db26c324c1de19f9f1
> Head: tytso-patches-20070223
> Author: Theodore Ts'o <tytso@mit.edu>
> Date:   Fri Feb 23 14:46:01 2007 -0500
> 
> Cherry pick "unload head on shutdown" patch
> 
> ...
> 
> commit c8f71b01a50597e298dc3214a2f2be7b8d31170c
> Tag: v2.6.21-rc1
> Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
> Date:   Tue Feb 20 20:32:30 2007 -0800
> 
>     Linux 2.6.21-rc1
> 
> Would there be objections in adding this to --pretty=medium (i.e., the
> default), or would it be better to add something like tihs to
> --pretty=full or --pretty=fuller?
> 
> 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.
> 
> 						- Ted

I'll do this gitk jump very often, too. Just to get the big picture where my branches are (inside the commit graph). As they stay normaly on the tip, I exit gitk long before it reached the root commit. What I'd like to have is something which shows me _visually_ the the branches, e.g.

master
| next			commit comment for next
o  |		commit comment for master~1
|  o			commit comment for next~1
o  |	[ ... guess whats next :-)		you get the idea ...]
|  o
|  |
o /
|

tig comes near it, but it only linerarises the branches, so you can't see where there was a mergepoint/fork. I'd really like these visuallization of the commit graph in some of the text viewers. I normally don't care about the _full_ commit text, only if I visually understand what's happening I'm looking at the individual commits and the patches.

There was some tool (can't remember its name or who it wrote; but posted here on this list) which visualizes the relation horizontaly and not vertically as shown above but has a limit of only displaying around 25 (not sure about this number; but definitly below 30 commits) which was at least displaying the commit graph which is _really_ really what I need.

-Peter
J. Bruce Fields· Apr 16, 2007, 18:27 UTC · re: Peter Baumann · lore

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

On Mon, Apr 16, 2007 at 08:13:52PM +0200, Peter Baumann wrote:
Show 14 quoted lines
> I'll do this gitk jump very often, too. Just to get the big picture where my
> branches are (inside the commit graph). As they stay normaly on the tip, I
> exit gitk long before it reached the root commit. What I'd like to have is
> something which shows me _visually_ the the branches, e.g.
> 
> master
> | next			commit comment for next
> o  |		commit comment for master~1
> |  o			commit comment for next~1
> o  |	[ ... guess whats next :-)		you get the idea ...]
> |  o
> |  |
> o /
> |
git show-branch?
--b.
Peter Baumann· Apr 17, 2007, 05:07 UTC · re: J. Bruce Fields · lore

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

On Mon, Apr 16, 2007 at 02:27:49PM -0400, J. Bruce Fields wrote:
Show 19 quoted lines
> On Mon, Apr 16, 2007 at 08:13:52PM +0200, Peter Baumann wrote:
> > I'll do this gitk jump very often, too. Just to get the big picture where my
> > branches are (inside the commit graph). As they stay normaly on the tip, I
> > exit gitk long before it reached the root commit. What I'd like to have is
> > something which shows me _visually_ the the branches, e.g.
> > 
> > master
> > | next			commit comment for next
> > o  |		commit comment for master~1
> > |  o			commit comment for next~1
> > o  |	[ ... guess whats next :-)		you get the idea ...]
> > |  o
> > |  |
> > o /
> > |
> 
> git show-branch?
> 
> --b.

No. git-show-branch produces output like the snippet below, which is totally non obious to me. Yes, I could figure out what it means, but why the hell _should_ I if there are tools for which you have to look just for a second on the ouput to _fully_ understand whats happening?

-Peter
xp:~/src/git (master)$ git show-branch
! [editpatch] Merge branch 'maint'
 * [master] Merge branch 'jc/index-output'
  ! [pu] Merge branch 'jc/diff' into pu
---
 -  [master] Merge branch 'jc/index-output'
 *  [master^2] git-read-tree --index-output=<file>
 *  [master^2^] _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
 *  [master^^2] Makefile: Add '+' to QUIET_SUBDIR0 to fix parallel make.
 *  [master~2^2] git-bisect: allow bisecting with only one bad commit.
 *  [master~2^2^] t6030: add a bit more tests to git-bisect
 *  [master~2^2~2] git-bisect: moderni
...
J. Bruce Fields· Apr 17, 2007, 13:36 UTC · re: Peter Baumann · lore

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

On Tue, Apr 17, 2007 at 07:07:04AM +0200, Peter Baumann wrote:
Show 25 quoted lines
> On Mon, Apr 16, 2007 at 02:27:49PM -0400, J. Bruce Fields wrote:
> > On Mon, Apr 16, 2007 at 08:13:52PM +0200, Peter Baumann wrote:
> > > I'll do this gitk jump very often, too. Just to get the big picture where my
> > > branches are (inside the commit graph). As they stay normaly on the tip, I
> > > exit gitk long before it reached the root commit. What I'd like to have is
> > > something which shows me _visually_ the the branches, e.g.
> > > 
> > > master
> > > | next			commit comment for next
> > > o  |		commit comment for master~1
> > > |  o			commit comment for next~1
> > > o  |	[ ... guess whats next :-)		you get the idea ...]
> > > |  o
> > > |  |
> > > o /
> > > |
> > 
> > git show-branch?
> > 
> > --b.
> 
> No. git-show-branch produces output like the snippet below, which is totally
> non obious to me. Yes, I could figure out what it means, but why the hell
> _should_ I if there are tools for which you have to look just for a second
> on the ouput to _fully_ understand whats happening?
Yeah, I find it pretty opaque too.--b.
Julian Phillips· Apr 16, 2007, 19:01 UTC · re: Peter Baumann · lore

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

On Mon, 16 Apr 2007, Peter Baumann wrote:
Show 16 quoted lines
>
> master
> | next			commit comment for next
> o  |		commit comment for master~1
> |  o			commit comment for next~1
> o  |	[ ... guess whats next :-)		you get the idea ...]
> |  o
> |  |
> o /
> |
>
> tig comes near it, but it only linerarises the branches, so you can't see
> where there was a mergepoint/fork. I'd really like these visuallization of
> the commit graph in some of the text viewers. I normally don't care about
> the _full_ commit text, only if I visually understand what's happening I'm
> looking at the individual commits and the patches.

If you turn on the revision graph visualisation (press 'g' whil in main view) then tig will show merges and forks ... looks a little like your diagram above in fact.

-- 
Julian

  ---
The climate of Bombay is such that its inhabitants have to live elsewhere.
Peter Baumann· Apr 17, 2007, 05:08 UTC · re: Julian Phillips · lore

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

On Mon, Apr 16, 2007 at 08:01:29PM +0100, Julian Phillips wrote:
Show 26 quoted lines
>  On Mon, 16 Apr 2007, Peter Baumann wrote:
> 
> >
> > master
> > | next			commit comment for next
> > o  |		commit comment for master~1
> > |  o			commit comment for next~1
> > o  |	[ ... guess whats next :-)		you get the idea ...]
> > |  o
> > |  |
> > o /
> > |
> >
> > tig comes near it, but it only linerarises the branches, so you can't see
> > where there was a mergepoint/fork. I'd really like these visuallization of
> > the commit graph in some of the text viewers. I normally don't care about
> > the _full_ commit text, only if I visually understand what's happening I'm
> > looking at the individual commits and the patches.
> 
>  If you turn on the revision graph visualisation (press 'g' whil in main 
>  view) then tig will show merges and forks ... looks a little like your 
>  diagram above in fact.
> 
>  -- 
>  Julian
> 
Nice. I didn't now of this feature.
Peter
Linus Torvalds· Apr 16, 2007, 23:00 UTC · re: Theodore Ts'o · lore

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

On Mon, 16 Apr 2007, Theodore Ts'o wrote:
Show 10 quoted lines
> 
> 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:
Ok, the next few emails will send out a series of two patches to do this.

The patches are much larger than necessary, because the way I did it was to add a totally generic notion of "object decorations", ie random data structures that can be attached to an object.

I actually stole the implementation from "object-refs", and in fact made object refs just be a normal decoration.

The exact syntax is up in the air, but with this, I can say
	git log --decorate

(we could obviously make the "--decorate" thing be the default if really wants to), and it will result in something like this:

	commit 02cfc097c2351a2b6e3a65626ce619f038f73c03 (refs/heads/master)
	Author: Linus Torvalds <torvalds@osdl.org>
	Date:   Mon Apr 16 15:49:58 2007 -0700
	
	    Add support for "commit name decorations" to log family of commands
	
	    Right now, it adds "--decorate" as a log option, which prints out the
	    ref names that point to that object if any.
	
	    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
	
	commit b1beb21820bea9c2fb9c04019c485d7810cba710 (refs/tags/test-tag)
	Author: Linus Torvalds <torvalds@osdl.org>
	Date:   Mon Apr 16 15:11:54 2007 -0700
	
	    Add a generic "object decorator" interface, and make object refs use it
	
	    This allows you to add an arbitrary "decoration" of your choice to any
	    object.  It's a space- and time-efficient way to add information to
	    arbitrary objects, especially if most objects probably do not have the
	    decoration.
	
	    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
	
	commit 7a1593972c19df26aee7d14c7d7c8c4fce24fb26 (refs/heads/parent)
	Merge: b073211... 5f2e1df...
	Author: Junio C Hamano <junkio@cox.net>
	Date:   Sun Apr 15 17:52:07 2007 -0700
	
	    Merge branch 'maint'
	....

ie notice the "decorations" after the commit name that actually tell what branch that commit is on.

A commit may obviously be on multiple branches, in which case it will have multiple decorations, and they will show up like so:

	commit 1ed91937e5cd59fdbdfa5f15f6fac132d2b21ce0 (tag: refs/tags/v1.0rc6, tag: refs/tags/v0.99.9n)

where that is an example of a commit that is tagged with two different tag objects (it's also an example of the difference of having a direct ref to it and having a ref that is a tag object that points to it: see the "refs/tags/test-tag" example above on what a *direct* tag reference will look like, while the "tag: refs/tags/xyzzy" format means that it's an *indirect* reference through a tag object.

Patches to follow.
		Linus
Theodore Tso· Apr 17, 2007, 02:21 UTC · re: Linus Torvalds · lore

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

On Mon, Apr 16, 2007 at 04:00:38PM -0700, Linus Torvalds wrote:
> 	commit 02cfc097c2351a2b6e3a65626ce619f038f73c03 (refs/heads/master)

Nice! And you did it far more efficiently than I probably would have done it if I tried to code it. :-)

The one thing that's a bit unfortunate is that with the commit ID taking up 40 characters, very often there's not enough space on the screen to display all of the tags and references (and with the default less options being hardcoded as "-FRSX", the ones that go beyond the width of the screen get lost.

So I tried to use --abbrev, and it didn't shrink the size of the id, like I thought it would. It didn't object to the option, but apparently it ignored it. Funny, I thought it worked before, but it wasn't before I applied the patch, so it wasn't your patches that were at fault.

It would be nice if the --pretty=format had a way of specifying the decorations, so it would be possible to have a format more like:

Author: Linus Torvalds <torvalds@osdl.org>
Date:   Mon Apr 16 15:49:58 2007 -0700
Head: origin/master
Head: master
Tag: v2.6.20-rc7-ext4-1 (signed)

... but that's something I can work on supplying as a patch, given that you've written the underlying machinery.

					- Ted
Jakub Narebski· Apr 17, 2007, 02:30 UTC · re: Theodore Tso · lore

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

Theodore Tso wrote:
Show 11 quoted lines
> The one thing that's a bit unfortunate is that with the commit ID
> taking up 40 characters, very often there's not enough space on the
> screen to display all of the tags and references (and with the default
> less options being hardcoded as "-FRSX", the ones that go beyond the
> width of the screen get lost.  
> 
> So I tried to use --abbrev, and it didn't shrink the size of the id,
> like I thought it would.  It didn't object to the option, but
> apparently it ignored it.  Funny, I thought it worked before, but it
> wasn't before I applied the patch, so it wasn't your patches that were
> at fault.

You have to use --abbrev-commit (--abbrev is opassed to log machinery, and covers object ids), which is undocumented option (mentioned only in passing in git-reflog(1)).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Linus Torvalds· Apr 17, 2007, 03:00 UTC · re: Jakub Narebski · lore

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

On Tue, 17 Apr 2007, Jakub Narebski wrote:
> 
> You have to use --abbrev-commit (--abbrev is opassed to log machinery, and
> covers object ids), which is undocumented option (mentioned only in passing
> in git-reflog(1)).

Yeah, it's irritated me often enough that I think we should just make "--abbrev" set "--abbrev-commit" too.

		Linus
Junio C Hamano· Apr 23, 2007, 10:00 UTC · re: Linus Torvalds · lore

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

Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 8 quoted lines
> On Tue, 17 Apr 2007, Jakub Narebski wrote:
>> 
>> You have to use --abbrev-commit (--abbrev is opassed to log machinery, and
>> covers object ids), which is undocumented option (mentioned only in passing
>> in git-reflog(1)).
>
> Yeah, it's irritated me often enough that I think we should just make 
> "--abbrev" set "--abbrev-commit" too.
Hmmm.  I do not know if this breaks anything...
---
 revision.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index ce70f48..78d144b 100644
--- a/revision.c
+++ b/revision.c
@@ -1081,6 +1081,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 			}
 			if (!strcmp(arg, "--abbrev")) {
 				revs->abbrev = DEFAULT_ABBREV;
+				revs->abbrev_commit = 1;
 				continue;
 			}
 			if (!prefixcmp(arg, "--abbrev=")) {
@@ -1089,6 +1090,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 					revs->abbrev = MINIMUM_ABBREV;
 				else if (revs->abbrev > 40)
 					revs->abbrev = 40;
+				else
+					revs->abbrev_commit = 1;
 				continue;
 			}
 			if (!strcmp(arg, "--abbrev-commit")) {
Theodore Tso· Apr 17, 2007, 03:15 UTC · re: Jakub Narebski · lore

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

On Tue, Apr 17, 2007 at 04:30:47AM +0200, Jakub Narebski wrote:
> You have to use --abbrev-commit (--abbrev is opassed to log machinery, and
> covers object ids), which is undocumented option (mentioned only in passing
> in git-reflog(1)).

Sigh, I found --abbrev first from deferencing the following paragraph from the git-log man page:

   The [git-log] command takes options applicable to the
   git-rev-list(1) command to control what is shown and how, and
   options applicable to the git-diff-tree(1) commands to control how
   the changes each commit introduces are shown.

In any case, --abrev is mentioned in git-rev-list(1)'s man page, and specifying it doesn't cause git-log to bomb out with an illegal option name. It just apparently ignores it as far as I can tell.

						- Ted

← back to recent threads