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

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

[Theodore Ts'o]

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

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

[Junio C Hamano]

"Theodore Ts'o" <tytso@mit.edu> 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

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

[Peter Baumann]

On Mon, Apr 16, 2007 at 08:45:55AM -0400, Theodore Ts'o wrote:
> 
> 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

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

[J. Bruce Fields]

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.

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

[Julian Phillips]

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

  ---
The climate of Bombay is such that its inhabitants have to live elsewhere.

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

[Theodore Tso]

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

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

[Linus Torvalds]

On Mon, 16 Apr 2007, Theodore Ts'o wrote:
> 
> 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

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

[Theodore Tso]

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

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

[Jakub Narebski]

Theodore Tso wrote:

> 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

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

[Linus Torvalds]

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

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

[Theodore Tso]

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

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

[Peter Baumann]

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?

-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
...

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

[Peter Baumann]

On Mon, Apr 16, 2007 at 08:01:29PM +0100, Julian Phillips wrote:
>  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

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

[J. Bruce Fields]

On Tue, Apr 17, 2007 at 07:07:04AM +0200, Peter Baumann wrote:
> 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.

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> 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")) {