{"thread":{"id":"7677","subject":"Any objectsions to enhancing git-log to show tags/branch heads?","startedAt":"2007-04-16T12:45:55Z","lastAt":"2007-04-23T10:00:03Z","messageCount":15,"participants":["Theodore Ts'o","Junio C Hamano","Peter Baumann","J. Bruce Fields","Julian Phillips","Theodore Tso","Linus Torvalds","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39520","messageId":"E1HdQah-0008Q2-7E@candygram.thunk.org","threadId":"7677","inReplyTo":null,"subject":"Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Theodore Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2007-04-16T12:45:55Z","receivedAt":"2007-04-16T12:45:55Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"\nI've recently noticed that I'm often firing up gitk for no other purpose\nthan to see which changesets have which tags and branch heads. Often\nI'll fire up gitk, quickly look at the tags/branches, and then kill it\nbefore it's done parsing the repository, resulting in python errors as\nit dies.\n\nSo I'm wondering why we haven't arranged to have git-log show this\ninformation, and whether there would be any objections if \"git-log\"\nshowed something like this:\n\ncommit 7d5021d2ef5d414908d8e4db26c324c1de19f9f1\nHead: tytso-patches-20070223\nAuthor: Theodore Ts'o \nDate: Fri Feb 23 14:46:01 2007 -0500\n\nCherry pick \"unload head on shutdown\" patch\n\n...\n\ncommit c8f71b01a50597e298dc3214a2f2be7b8d31170c\nTag: v2.6.21-rc1\nAuthor: Linus Torvalds \nDate: Tue Feb 20 20:32:30 2007 -0800\n\n Linux 2.6.21-rc1\n\nWould there be objections in adding this to --pretty=medium (i.e., the\ndefault), or would it be better to add something like tihs to\n--pretty=full or --pretty=fuller?\n\nThe only reason why I could imagine not doing this by default would be a\npotential performance problem if there were thousands of heads or branch\nheads.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"39558","messageId":"7vy7kstdom.fsf@assigned-by-dhcp.cox.net","threadId":"7677","inReplyTo":"E1HdQah-0008Q2-7E@candygram.thunk.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-16T17:46:33Z","receivedAt":"2007-04-16T17:46:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Theodore Ts'o\" writes:\n\n> I've recently noticed that I'm often firing up gitk for no other purpose\n> than to see which changesets have which tags and branch heads. Often\n> I'll fire up gitk, quickly look at the tags/branches, and then kill it\n> before it's done parsing the repository, resulting in python errors as\n> it dies.\n>\n> So I'm wondering why we haven't arranged to have git-log show this\n> information, and whether there would be any objections if \"git-log\"\n> showed something like this:\n> ...\n> The only reason why I could imagine not doing this by default would be a\n> potential performance problem if there were thousands of heads or branch\n> heads.\n\nI cannot comment on performance impact without knowing exactly\nwhat semantics is being proposed.\n\n (1) If a commit is not directly pointed by any ref, would it\n get HEAD: or TAG: line, perhaps ala 'git-describe'?\n\n (2) If a commit is at the tip of two branches, what happens?\n Would it get two HEAD: lines?\n\n (3) Same question as (2) when a commit is tagged with two tags,\n or at the tip of a branch and pointed by a tag.\n\nAs to the impact on people's existing scripts that read git-log,\nI think changing --pretty=anything would cause breakage for\nsomebody. A new --pretty=format: tag would be the least\ndestabilizing, but I dunno.\n\nBut the fact that you kill gitk before it stops drawing suggests\nthat you are interested in recent commits only? What is exactly\nthe use case? What I am wondering is:\n\n (a) you have a handful specific commit IDs and wondering what\n they are, relative to known anchoring points.\n\n If this is the case, git-describe and git-name-rev may be\n your friend.\n\n (b) whenever you are browsing random part of history, you often\n wonder which ones are tagged or at the tip. Browsing \"git\n log\" output does not give the visual cue of anchoring\n points like \"gitk\" output does, which annoys you.\n\n A code-free way to help with this is:\n\n $ git log | git -p name-rev --stdin\n"},{"id":"39560","messageId":"20070416181352.GB29569@xp.machine.xx","threadId":"7677","inReplyTo":"E1HdQah-0008Q2-7E@candygram.thunk.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Peter Baumann","fromEmail":"peter.baumann@gmail.com","sentAt":"2007-04-16T18:13:52Z","receivedAt":"2007-04-16T18:13:52Z","isPatch":false,"sender":{"key":"peter.baumann@gmail.com","avatar":null},"body":"On Mon, Apr 16, 2007 at 08:45:55AM -0400, Theodore Ts'o wrote:\n> \n> I've recently noticed that I'm often firing up gitk for no other purpose\n> than to see which changesets have which tags and branch heads. Often\n> I'll fire up gitk, quickly look at the tags/branches, and then kill it\n> before it's done parsing the repository, resulting in python errors as\n> it dies.\n> \n> So I'm wondering why we haven't arranged to have git-log show this\n> information, and whether there would be any objections if \"git-log\"\n> showed something like this:\n> \n> commit 7d5021d2ef5d414908d8e4db26c324c1de19f9f1\n> Head: tytso-patches-20070223\n> Author: Theodore Ts'o \n> Date: Fri Feb 23 14:46:01 2007 -0500\n> \n> Cherry pick \"unload head on shutdown\" patch\n> \n> ...\n> \n> commit c8f71b01a50597e298dc3214a2f2be7b8d31170c\n> Tag: v2.6.21-rc1\n> Author: Linus Torvalds \n> Date: Tue Feb 20 20:32:30 2007 -0800\n> \n> Linux 2.6.21-rc1\n> \n> Would there be objections in adding this to --pretty=medium (i.e., the\n> default), or would it be better to add something like tihs to\n> --pretty=full or --pretty=fuller?\n> \n> The only reason why I could imagine not doing this by default would be a\n> potential performance problem if there were thousands of heads or branch\n> heads.\n> \n> \t\t\t\t\t\t- Ted\n\nI'll do this gitk jump very often, too. Just to get the big picture where my\nbranches are (inside the commit graph). As they stay normaly on the tip, I\nexit gitk long before it reached the root commit. What I'd like to have is\nsomething which shows me _visually_ the the branches, e.g.\n\nmaster\n| next\t\t\tcommit comment for next\no |\t\tcommit comment for master~1\n| o\t\t\tcommit comment for next~1\no |\t[ ... guess whats next :-)\t\tyou get the idea ...]\n| o\n| |\no /\n|\n\ntig comes near it, but it only linerarises the branches, so you can't see\nwhere there was a mergepoint/fork. I'd really like these visuallization of\nthe commit graph in some of the text viewers. I normally don't care about\nthe _full_ commit text, only if I visually understand what's happening I'm\nlooking at the individual commits and the patches.\n\nThere was some tool (can't remember its name or who it wrote; but posted\nhere on this list) which visualizes the relation horizontaly and not\nvertically as shown above but has a limit of only displaying around 25 (not\nsure about this number; but definitly below 30 commits) which was at least\ndisplaying the commit graph which is _really_ really what I need.\n\n-Peter\n"},{"id":"39562","messageId":"20070416182749.GG23764@fieldses.org","threadId":"7677","inReplyTo":"20070416181352.GB29569@xp.machine.xx","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-04-16T18:27:49Z","receivedAt":"2007-04-16T18:27:49Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Mon, Apr 16, 2007 at 08:13:52PM +0200, Peter Baumann wrote:\n> I'll do this gitk jump very often, too. Just to get the big picture where my\n> branches are (inside the commit graph). As they stay normaly on the tip, I\n> exit gitk long before it reached the root commit. What I'd like to have is\n> something which shows me _visually_ the the branches, e.g.\n> \n> master\n> | next\t\t\tcommit comment for next\n> o |\t\tcommit comment for master~1\n> | o\t\t\tcommit comment for next~1\n> o |\t[ ... guess whats next :-)\t\tyou get the idea ...]\n> | o\n> | |\n> o /\n> |\n\ngit show-branch?\n\n--b.\n"},{"id":"39566","messageId":"Pine.LNX.4.64.0704161958470.6021@reaper.quantumfyre.co.uk","threadId":"7677","inReplyTo":"20070416181352.GB29569@xp.machine.xx","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-04-16T19:01:29Z","receivedAt":"2007-04-16T19:01:29Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Mon, 16 Apr 2007, Peter Baumann wrote:\n\n>\n> master\n> | next\t\t\tcommit comment for next\n> o |\t\tcommit comment for master~1\n> | o\t\t\tcommit comment for next~1\n> o |\t[ ... guess whats next :-)\t\tyou get the idea ...]\n> | o\n> | |\n> o /\n> |\n>\n> tig comes near it, but it only linerarises the branches, so you can't see\n> where there was a mergepoint/fork. I'd really like these visuallization of\n> the commit graph in some of the text viewers. I normally don't care about\n> the _full_ commit text, only if I visually understand what's happening I'm\n> looking at the individual commits and the patches.\n\nIf you turn on the revision graph visualisation (press 'g' whil in main \nview) then tig will show merges and forks ... looks a little like your \ndiagram above in fact.\n\n-- \nJulian\n\n ---\nThe climate of Bombay is such that its inhabitants have to live elsewhere.\n"},{"id":"39575","messageId":"20070416204659.GI27533@thunk.org","threadId":"7677","inReplyTo":"7vy7kstdom.fsf@assigned-by-dhcp.cox.net","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-04-16T20:46:59Z","receivedAt":"2007-04-16T20:46:59Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 16, 2007 at 10:46:33AM -0700, Junio C Hamano wrote:\n> I cannot comment on performance impact without knowing exactly\n> what semantics is being proposed.\n> \n> (1) If a commit is not directly pointed by any ref, would it\n> get HEAD: or TAG: line, perhaps ala 'git-describe'?\n\nNo.\n\n> (2) If a commit is at the tip of two branches, what happens?\n> Would it get two HEAD: lines?\n\nYup, I was assuming it would get two Head: lines, one for each head.\n\n> (3) Same question as (2) when a commit is tagged with two tags,\n> or at the tip of a branch and pointed by a tag.\n\nTwo tag: lines, one for each tag. Mercurial's \"hg log\" does this\ntoday, by the way, and I've found it to be very handy since it makes\nit easier to find various tagged releases when browsing the revision\nhistory.\n\n> As to the impact on people's existing scripts that read git-log,\n> I think changing --pretty=anything would cause breakage for\n> somebody. A new --pretty=format: tag would be the least\n> destabilizing, but I dunno.\n\nWhen I write my shell scripts and parse \"Foo: \" headers I always\nexplicitly grep out the headers I want, and assumin a blank line after\nthe headers, because I expect that future versions might add new\nheaders, and I want my code to be robust; but I can imagine there\nmight be some less-than-robust scripts out there....\n\n> But the fact that you kill gitk before it stops drawing suggests\n> that you are interested in recent commits only? What is exactly the\n> use case?\n\nWell, usually what I'm interested in is near the tip, but not always.\nIn general, seeing the anchor points is part of the problem, and so\n\"git log | git -p name-rev --stdin\" is useful, although it isn't as\nuseful as \"gitk\" when a revision has multiple HEAD or TAG's associated\nwith it, and git-name-rev doesn't know which one(s) would be of\ngreatest interest.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"39577","messageId":"Pine.LNX.4.64.0704161552160.5473@woody.linux-foundation.org","threadId":"7677","inReplyTo":"E1HdQah-0008Q2-7E@candygram.thunk.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-16T23:00:38Z","receivedAt":"2007-04-16T23:00:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 16 Apr 2007, Theodore Ts'o wrote:\n> \n> I've recently noticed that I'm often firing up gitk for no other purpose\n> than to see which changesets have which tags and branch heads. Often\n> I'll fire up gitk, quickly look at the tags/branches, and then kill it\n> before it's done parsing the repository, resulting in python errors as\n> it dies.\n> \n> So I'm wondering why we haven't arranged to have git-log show this\n> information, and whether there would be any objections if \"git-log\"\n> showed something like this:\n\nOk, the next few emails will send out a series of two patches to do this.\n\nThe patches are much larger than necessary, because the way I did it was \nto add a totally generic notion of \"object decorations\", ie random data \nstructures that can be attached to an object.\n\nI actually stole the implementation from \"object-refs\", and in fact made \nobject refs just be a normal decoration.\n\nThe exact syntax is up in the air, but with this, I can say\n\n\tgit log --decorate\n\n(we could obviously make the \"--decorate\" thing be the default if really \nwants to), and it will result in something like this:\n\n\tcommit 02cfc097c2351a2b6e3a65626ce619f038f73c03 (refs/heads/master)\n\tAuthor: Linus Torvalds \n\tDate: Mon Apr 16 15:49:58 2007 -0700\n\t\n\t Add support for \"commit name decorations\" to log family of commands\n\t\n\t Right now, it adds \"--decorate\" as a log option, which prints out the\n\t ref names that point to that object if any.\n\t\n\t Signed-off-by: Linus Torvalds \n\t\n\tcommit b1beb21820bea9c2fb9c04019c485d7810cba710 (refs/tags/test-tag)\n\tAuthor: Linus Torvalds \n\tDate: Mon Apr 16 15:11:54 2007 -0700\n\t\n\t Add a generic \"object decorator\" interface, and make object refs use it\n\t\n\t This allows you to add an arbitrary \"decoration\" of your choice to any\n\t object. It's a space- and time-efficient way to add information to\n\t arbitrary objects, especially if most objects probably do not have the\n\t decoration.\n\t\n\t Signed-off-by: Linus Torvalds \n\t\n\tcommit 7a1593972c19df26aee7d14c7d7c8c4fce24fb26 (refs/heads/parent)\n\tMerge: b073211... 5f2e1df...\n\tAuthor: Junio C Hamano \n\tDate: Sun Apr 15 17:52:07 2007 -0700\n\t\n\t Merge branch 'maint'\n\t....\n\nie notice the \"decorations\" after the commit name that actually tell\nwhat branch that commit is on. \n\nA commit may obviously be on multiple branches, in which case it will\nhave multiple decorations, and they will show up like so:\n\n\tcommit 1ed91937e5cd59fdbdfa5f15f6fac132d2b21ce0 (tag: refs/tags/v1.0rc6, tag: refs/tags/v0.99.9n)\n\nwhere that is an example of a commit that is tagged with two different\ntag objects (it's also an example of the difference of having a direct\nref to it and having a ref that is a tag object that points to it: see\nthe \"refs/tags/test-tag\" example above on what a *direct* tag reference\nwill look like, while the \"tag: refs/tags/xyzzy\" format means that it's\nan *indirect* reference through a tag object.\n\nPatches to follow.\n\n\t\tLinus\n"},{"id":"39586","messageId":"20070417022154.GC30340@thunk.org","threadId":"7677","inReplyTo":"Pine.LNX.4.64.0704161552160.5473@woody.linux-foundation.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-04-17T02:21:54Z","receivedAt":"2007-04-17T02:21:54Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Apr 16, 2007 at 04:00:38PM -0700, Linus Torvalds wrote:\n> \tcommit 02cfc097c2351a2b6e3a65626ce619f038f73c03 (refs/heads/master)\n\nNice! And you did it far more efficiently than I probably would have\ndone it if I tried to code it. :-)\n\nThe one thing that's a bit unfortunate is that with the commit ID\ntaking up 40 characters, very often there's not enough space on the\nscreen to display all of the tags and references (and with the default\nless options being hardcoded as \"-FRSX\", the ones that go beyond the\nwidth of the screen get lost. \n\nSo I tried to use --abbrev, and it didn't shrink the size of the id,\nlike I thought it would. It didn't object to the option, but\napparently it ignored it. Funny, I thought it worked before, but it\nwasn't before I applied the patch, so it wasn't your patches that were\nat fault.\n\nIt would be nice if the --pretty=format had a way of specifying the\ndecorations, so it would be possible to have a format more like:\n\nAuthor: Linus Torvalds \nDate: Mon Apr 16 15:49:58 2007 -0700\nHead: origin/master\nHead: master\nTag: v2.6.20-rc7-ext4-1 (signed)\n\n... but that's something I can work on supplying as a patch, given\nthat you've written the underlying machinery.\n\n\t\t\t\t\t- Ted\n"},{"id":"39587","messageId":"f01b9g$qqc$1@sea.gmane.org","threadId":"7677","inReplyTo":"20070417022154.GC30340@thunk.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-04-17T02:30:47Z","receivedAt":"2007-04-17T02:30:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Theodore Tso wrote:\n\n> The one thing that's a bit unfortunate is that with the commit ID\n> taking up 40 characters, very often there's not enough space on the\n> screen to display all of the tags and references (and with the default\n> less options being hardcoded as \"-FRSX\", the ones that go beyond the\n> width of the screen get lost.  \n> \n> So I tried to use --abbrev, and it didn't shrink the size of the id,\n> like I thought it would.  It didn't object to the option, but\n> apparently it ignored it.  Funny, I thought it worked before, but it\n> wasn't before I applied the patch, so it wasn't your patches that were\n> at fault.\n\nYou have to use --abbrev-commit (--abbrev is opassed to log machinery, and\ncovers object ids), which is undocumented option (mentioned only in passing\nin git-reflog(1)).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"39591","messageId":"Pine.LNX.4.64.0704161959230.5473@woody.linux-foundation.org","threadId":"7677","inReplyTo":"f01b9g$qqc$1@sea.gmane.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-17T03:00:24Z","receivedAt":"2007-04-17T03:00:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 17 Apr 2007, Jakub Narebski wrote:\n> \n> You have to use --abbrev-commit (--abbrev is opassed to log machinery, and\n> covers object ids), which is undocumented option (mentioned only in passing\n> in git-reflog(1)).\n\nYeah, it's irritated me often enough that I think we should just make \n\"--abbrev\" set \"--abbrev-commit\" too.\n\n\t\tLinus\n"},{"id":"39592","messageId":"20070417031552.GA18373@thunk.org","threadId":"7677","inReplyTo":"f01b9g$qqc$1@sea.gmane.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-04-17T03:15:52Z","receivedAt":"2007-04-17T03:15:52Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Tue, Apr 17, 2007 at 04:30:47AM +0200, Jakub Narebski wrote:\n> You have to use --abbrev-commit (--abbrev is opassed to log machinery, and\n> covers object ids), which is undocumented option (mentioned only in passing\n> in git-reflog(1)).\n\nSigh, I found --abbrev first from deferencing the following paragraph\nfrom the git-log man page:\n\n The [git-log] command takes options applicable to the\n git-rev-list(1) command to control what is shown and how, and\n options applicable to the git-diff-tree(1) commands to control how\n the changes each commit introduces are shown.\n\nIn any case, --abrev is mentioned in git-rev-list(1)'s man page, and\nspecifying it doesn't cause git-log to bomb out with an illegal option\nname. It just apparently ignores it as far as I can tell.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"39607","messageId":"20070417050704.GA19925@xp.machine.xx","threadId":"7677","inReplyTo":"20070416182749.GG23764@fieldses.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Peter Baumann","fromEmail":"peter.baumann@gmail.com","sentAt":"2007-04-17T05:07:04Z","receivedAt":"2007-04-17T05:07:04Z","isPatch":false,"sender":{"key":"peter.baumann@gmail.com","avatar":null},"body":"On Mon, Apr 16, 2007 at 02:27:49PM -0400, J. Bruce Fields wrote:\n> On Mon, Apr 16, 2007 at 08:13:52PM +0200, Peter Baumann wrote:\n> > I'll do this gitk jump very often, too. Just to get the big picture where my\n> > branches are (inside the commit graph). As they stay normaly on the tip, I\n> > exit gitk long before it reached the root commit. What I'd like to have is\n> > something which shows me _visually_ the the branches, e.g.\n> > \n> > master\n> > | next\t\t\tcommit comment for next\n> > o |\t\tcommit comment for master~1\n> > | o\t\t\tcommit comment for next~1\n> > o |\t[ ... guess whats next :-)\t\tyou get the idea ...]\n> > | o\n> > | |\n> > o /\n> > |\n> \n> git show-branch?\n> \n> --b.\n\nNo. git-show-branch produces output like the snippet below, which is totally\nnon obious to me. Yes, I could figure out what it means, but why the hell\n_should_ I if there are tools for which you have to look just for a second\non the ouput to _fully_ understand whats happening?\n\n-Peter\n\nxp:~/src/git (master)$ git show-branch\n! [editpatch] Merge branch 'maint'\n * [master] Merge branch 'jc/index-output'\n ! [pu] Merge branch 'jc/diff' into pu\n---\n - [master] Merge branch 'jc/index-output'\n * [master^2] git-read-tree --index-output=\n * [master^2^] _GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.\n * [master^^2] Makefile: Add '+' to QUIET_SUBDIR0 to fix parallel make.\n * [master~2^2] git-bisect: allow bisecting with only one bad commit.\n * [master~2^2^] t6030: add a bit more tests to git-bisect\n * [master~2^2~2] git-bisect: moderni\n...\n"},{"id":"39611","messageId":"20070417050808.GC29569@xp.machine.xx","threadId":"7677","inReplyTo":"Pine.LNX.4.64.0704161958470.6021@reaper.quantumfyre.co.uk","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-04-17T05:08:08Z","receivedAt":"2007-04-17T05:08:08Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Mon, Apr 16, 2007 at 08:01:29PM +0100, Julian Phillips wrote:\n> On Mon, 16 Apr 2007, Peter Baumann wrote:\n> \n> >\n> > master\n> > | next\t\t\tcommit comment for next\n> > o |\t\tcommit comment for master~1\n> > | o\t\t\tcommit comment for next~1\n> > o |\t[ ... guess whats next :-)\t\tyou get the idea ...]\n> > | o\n> > | |\n> > o /\n> > |\n> >\n> > tig comes near it, but it only linerarises the branches, so you can't see\n> > where there was a mergepoint/fork. I'd really like these visuallization of\n> > the commit graph in some of the text viewers. I normally don't care about\n> > the _full_ commit text, only if I visually understand what's happening I'm\n> > looking at the individual commits and the patches.\n> \n> If you turn on the revision graph visualisation (press 'g' whil in main \n> view) then tig will show merges and forks ... looks a little like your \n> diagram above in fact.\n> \n> -- \n> Julian\n> \n\nNice. I didn't now of this feature.\n\nPeter\n"},{"id":"39643","messageId":"20070417133652.GC11907@fieldses.org","threadId":"7677","inReplyTo":"20070417050704.GA19925@xp.machine.xx","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-04-17T13:36:52Z","receivedAt":"2007-04-17T13:36:52Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Tue, Apr 17, 2007 at 07:07:04AM +0200, Peter Baumann wrote:\n> On Mon, Apr 16, 2007 at 02:27:49PM -0400, J. Bruce Fields wrote:\n> > On Mon, Apr 16, 2007 at 08:13:52PM +0200, Peter Baumann wrote:\n> > > I'll do this gitk jump very often, too. Just to get the big picture where my\n> > > branches are (inside the commit graph). As they stay normaly on the tip, I\n> > > exit gitk long before it reached the root commit. What I'd like to have is\n> > > something which shows me _visually_ the the branches, e.g.\n> > > \n> > > master\n> > > | next\t\t\tcommit comment for next\n> > > o |\t\tcommit comment for master~1\n> > > | o\t\t\tcommit comment for next~1\n> > > o |\t[ ... guess whats next :-)\t\tyou get the idea ...]\n> > > | o\n> > > | |\n> > > o /\n> > > |\n> > \n> > git show-branch?\n> > \n> > --b.\n> \n> No. git-show-branch produces output like the snippet below, which is totally\n> non obious to me. Yes, I could figure out what it means, but why the hell\n> _should_ I if there are tools for which you have to look just for a second\n> on the ouput to _fully_ understand whats happening?\n\nYeah, I find it pretty opaque too.--b.\n"},{"id":"40186","messageId":"7vd51vh0m4.fsf@assigned-by-dhcp.cox.net","threadId":"7677","inReplyTo":"Pine.LNX.4.64.0704161959230.5473@woody.linux-foundation.org","subject":"Re: Any objectsions to enhancing git-log to show tags/branch heads?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-23T10:00:03Z","receivedAt":"2007-04-23T10:00:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 17 Apr 2007, Jakub Narebski wrote:\n>> \n>> You have to use --abbrev-commit (--abbrev is opassed to log machinery, and\n>> covers object ids), which is undocumented option (mentioned only in passing\n>> in git-reflog(1)).\n>\n> Yeah, it's irritated me often enough that I think we should just make \n> \"--abbrev\" set \"--abbrev-commit\" too.\n\nHmmm. I do not know if this breaks anything...\n\n---\n\n revision.c | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/revision.c b/revision.c\nindex ce70f48..78d144b 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -1081,6 +1081,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t}\n \t\t\tif (!strcmp(arg, \"--abbrev\")) {\n \t\t\t\trevs->abbrev = DEFAULT_ABBREV;\n+\t\t\t\trevs->abbrev_commit = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tif (!prefixcmp(arg, \"--abbrev=\")) {\n@@ -1089,6 +1090,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t\t\trevs->abbrev = MINIMUM_ABBREV;\n \t\t\t\telse if (revs->abbrev > 40)\n \t\t\t\t\trevs->abbrev = 40;\n+\t\t\t\telse\n+\t\t\t\t\trevs->abbrev_commit = 1;\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\tif (!strcmp(arg, \"--abbrev-commit\")) {\n"}]}