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 [off-list ref]
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 [off-list ref]
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
From: Peter Baumann <hidden> Date: 2016-06-15 22:43:04
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 [off-list ref]
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 [off-list ref]
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
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:43:04
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 /
|
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.
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 [off-list ref]
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 [off-list ref]
commit b1beb21820bea9c2fb9c04019c485d7810cba710 (refs/tags/test-tag)
Author: Linus Torvalds [off-list ref]
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 [off-list ref]
commit 7a1593972c19df26aee7d14c7d7c8c4fce24fb26 (refs/heads/parent)
Merge: b073211... 5f2e1df...
Author: Junio C Hamano [off-list ref]
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
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 [off-list ref]
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:43:04
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
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
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
From: Peter Baumann <hidden> Date: 2016-06-15 22:43:04
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:
quoted
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
...
From: Peter Baumann <hidden> Date: 2016-06-15 22:43:04
On Mon, Apr 16, 2007 at 08:01:29PM +0100, Julian Phillips wrote:
On Mon, 16 Apr 2007, Peter Baumann wrote:
quoted
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
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:43:05
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:
quoted
On Mon, Apr 16, 2007 at 08:13:52PM +0200, Peter Baumann wrote:
quoted
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?
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:06
Linus Torvalds [off-list ref] writes:
On Tue, 17 Apr 2007, Jakub Narebski wrote:
quoted
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(-)