{"thread":{"id":"13677","subject":"visualizing Git's Git repo","startedAt":"2008-05-26T20:47:33Z","lastAt":"2008-05-28T08:39:16Z","messageCount":9,"participants":["Joshua Haberman","Eric Hanchrow","Shawn O. Pearce","Björn Steinbrink","Jeff King","Linus Torvalds","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77795","messageId":"CA563F5A-5E12-42F7-BDFD-04FE3A882028@reverberate.org","threadId":"13677","inReplyTo":null,"subject":"visualizing Git's Git repo","fromName":"Joshua Haberman","fromEmail":"joshua@reverberate.org","sentAt":"2008-05-26T20:47:33Z","receivedAt":"2008-05-26T20:47:33Z","isPatch":false,"sender":{"key":"joshua@reverberate.org","avatar":"https://gravatar.com/avatar/d685b0ab746982f2a7c73d24ed7f13ba2412751bc1c4528d2899e642694a281a?d=mp&s=160"},"body":"I'm a casual Git user. One thing that's been troubling me about Git \nis that when I look at Git's own Git repository, the revision history \nis not at all easy to understand. I like to view my own Git \nrepositories with:\n\n$ gitk --all --date-order\n\nWhen I run this command, what I'm really asking is \"give me a visual \nsummary of what's up with my project lately.\" But with Git's \nrepository, there are far too many branches and merges for this view \nto make any kind of visual sense.\n\nSo my questions are:\n\n1. what do you all do to get a high-level view of what's going on with \nGit development? do you use gitk? if so, what options?\n\n2. as a project, why don't you rebase when merging long-running \nbranches into master? For example, take commit 7e83003029 from May 25 \nwhich merged a branch that was based at 4b172de81 from May 14. Why \nnot rebase this to May 25 as part of the merge? When you don't do \nthis (ie. in the status quo) 'gitk --date-order' for the Git \nrepository has >10 parallel branches most of the time, which makes it \nimpossible to follow visually.\n\nI'm sure you have reasons for doing things the way you do, I just want \nto hear what they are. And sorry if this is a FAQ -- feel free to \npoint me at any documentation that explains this.\n\nJosh\n"},{"id":"77812","messageId":"87ve104qoz.fsf@offby1.atm01.sea.blarg.net","threadId":"13677","inReplyTo":"CA563F5A-5E12-42F7-BDFD-04FE3A882028@reverberate.org","subject":"Re: visualizing Git's Git repo","fromName":"Eric Hanchrow","fromEmail":"offby1@blarg.net","sentAt":"2008-05-26T22:59:40Z","receivedAt":"2008-05-26T22:59:40Z","isPatch":false,"sender":{"key":"eric.hanchrow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3145?v=4"},"body":"You might not know -- I didn't until five minutes ago -- that you can\nomit entire branches, like this:\n\n $ gitk --all ^refs/remotes/origin/man ^refs/remotes/origin/html\n\n-- \nThe story will be familiar to anyone who has ever seen a movie about a\ntroubled athlete and a brilliant coach. It will also be familiar to\nanyone who has not. -- Roger Ebert, on \"Stick It\" (2006)\n"},{"id":"77818","messageId":"loom.20080526T233903-825@post.gmane.org","threadId":"13677","inReplyTo":"87ve104qoz.fsf@offby1.atm01.sea.blarg.net","subject":"Re: visualizing Git's Git repo","fromName":"Joshua Haberman","fromEmail":"joshua@reverberate.org","sentAt":"2008-05-26T23:42:24Z","receivedAt":"2008-05-26T23:42:24Z","isPatch":false,"sender":{"key":"joshua@reverberate.org","avatar":"https://gravatar.com/avatar/d685b0ab746982f2a7c73d24ed7f13ba2412751bc1c4528d2899e642694a281a?d=mp&s=160"},"body":"Eric Hanchrow blarg.net> writes:\n> \n> You might not know -- I didn't until five minutes ago -- that you can\n> omit entire branches, like this:\n> \n> $ gitk --all ^refs/remotes/origin/man ^refs/remotes/origin/html\n\nThanks for the tip -- I had tried the converse, which is to only include master,\nbut both this and your strategy still leave at least 10 concurrent branches at\nalmost any point in time.\n\nJosh\n"},{"id":"77820","messageId":"20080526234622.GG30245@spearce.org","threadId":"13677","inReplyTo":"87ve104qoz.fsf@offby1.atm01.sea.blarg.net","subject":"Re: visualizing Git's Git repo","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-26T23:46:22Z","receivedAt":"2008-05-26T23:46:22Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Eric Hanchrow wrote:\n> You might not know -- I didn't until five minutes ago -- that you can\n> omit entire branches, like this:\n> \n> $ gitk --all ^refs/remotes/origin/man ^refs/remotes/origin/html\n> \n\nAnd if you do this a lot you can remember it as a shorthand:\n\n\t$ git config alias.seeall '! gitk --all ^refs/remotes/origin/man ^refs/remotes/origin/html'\n\t$ git seeall\n\n-- \nShawn.\n"},{"id":"77824","messageId":"20080527004132.GA6400@atjola.homenet","threadId":"13677","inReplyTo":"CA563F5A-5E12-42F7-BDFD-04FE3A882028@reverberate.org","subject":"Re: visualizing Git's Git repo","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2008-05-27T00:41:32Z","receivedAt":"2008-05-27T00:41:32Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2008.05.26 13:47:33 -0700, Joshua Haberman wrote:\n> I'm a casual Git user. One thing that's been troubling me about Git is \n> that when I look at Git's own Git repository, the revision history is not \n> at all easy to understand. I like to view my own Git repositories with:\n>\n> $ gitk --all --date-order\n>\n> When I run this command, what I'm really asking is \"give me a visual \n> summary of what's up with my project lately.\" But with Git's \n> repository, there are far too many branches and merges for this view to \n> make any kind of visual sense.\n>\n> So my questions are:\n>\n> 1. what do you all do to get a high-level view of what's going on with \n> Git development? do you use gitk? if so, what options?\n\nDoesn't make much sense with --all, but if you only view one branch, eg.\norigin/master or origin/next, --no-merges might produce an output that's\nmore suitable for you.\n\nBjörn\n"},{"id":"77886","messageId":"loom.20080527T202009-498@post.gmane.org","threadId":"13677","inReplyTo":"CA563F5A-5E12-42F7-BDFD-04FE3A882028@reverberate.org","subject":"Re: visualizing Git's Git repo","fromName":"Joshua Haberman","fromEmail":"joshua@reverberate.org","sentAt":"2008-05-27T20:36:16Z","receivedAt":"2008-05-27T20:36:16Z","isPatch":false,"sender":{"key":"joshua@reverberate.org","avatar":"https://gravatar.com/avatar/d685b0ab746982f2a7c73d24ed7f13ba2412751bc1c4528d2899e642694a281a?d=mp&s=160"},"body":"Joshua Haberman reverberate.org> writes:\n> 1. what do you all do to get a high-level view of what's going on with \n> Git development? do you use gitk? if so, what options?\n\nI get the impression from this thread that core Git developers don't make\nvisualizing the repository a regular part of their development workflow. Is\nthat accurate? What do you all do to keep tabs on Git development?\n\n> 2. as a project, why don't you rebase when merging long-running \n> branches into master?\n\nIs there really no rationale that anyone can offer for why you do things this\nway? I look to Git's own Git repo for best practices, and given Git's emphasis\non \"history hygiene\" I'm certain that there are reasons for why you do things\nthe way you do.\n\nJosh\n"},{"id":"77906","messageId":"20080527234948.GA17424@sigill.intra.peff.net","threadId":"13677","inReplyTo":"loom.20080527T202009-498@post.gmane.org","subject":"Re: visualizing Git's Git repo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-05-27T23:49:48Z","receivedAt":"2008-05-27T23:49:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 27, 2008 at 08:36:16PM +0000, Joshua Haberman wrote:\n\n> > 1. what do you all do to get a high-level view of what's going on with \n> > Git development? do you use gitk? if so, what options?\n> \n> I get the impression from this thread that core Git developers don't make\n> visualizing the repository a regular part of their development workflow. Is\n> that accurate? What do you all do to keep tabs on Git development?\n\nI don't know if I count as a core Git developer, but I do use gitk daily\nto track what goes into Junio's repo. My refs are organized something\nlike:\n\n remotes/origin/* - tracking branches of Junio's git.git\n heads/jk/* - long running topics branched from master\n heads/next - Junio's next branch with short or temporary patches on top\n\nMy git day generally starts like this:\n\n git fetch ;# grab newly merged stuff\n gitk origin/next...next ;# see what's new\n git rebase origin/next ;# and bring ourselves up to date\n\nYou don't necessarily get to see all of the topic branches labeled\nindividually, but generally you see each merged topic preceded by the\n'Merge ...' commit.\n\nFor long running branches, I leave them alone until I'm ready to work on\nthem. And then it's:\n\n git checkout jk/whatever\n gitk origin/master.. ;# what was I doing again?\n git rebase origin/master ;# should be clean if nobody else\n # is touching the same area\n\nAnd if the rebase isn't clean, then I investigate individual areas with:\n\n gitk --no-merges jk/whatever...origin/master problematic_file.c\n\nSo maybe that is a bit of a boring workflow description, but I do\nvisualize with gitk all the time. I tend to do a lot of bug-hunting,\ntoo, for which I don't end up doing visualization. Instead, I almost\nalways rely on asking more specific questions about content: blame\n(especially \"tig blame\"), bisect, and pickaxe (\"git log -S\").\n\n-Peff\n"},{"id":"77910","messageId":"alpine.LFD.1.10.0805271957430.2958@woody.linux-foundation.org","threadId":"13677","inReplyTo":"CA563F5A-5E12-42F7-BDFD-04FE3A882028@reverberate.org","subject":"Re: visualizing Git's Git repo","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-05-28T03:15:13Z","receivedAt":"2008-05-28T03:15:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 26 May 2008, Joshua Haberman wrote:\n>\n> I'm a casual Git user. One thing that's been troubling me about Git is that\n> when I look at Git's own Git repository, the revision history is not at all\n> easy to understand. I like to view my own Git repositories with:\n> \n> $ gitk --all --date-order\n\nI would seriously suggest avoiding \"--date-order\" unless you have some \ndeep reason to see how the commits on different development paths relate \nto each other date-wise - something you should normally not have.\n\nThe thing is, --date-order strings out and mixes up the commits on the \nsame development chain, and by doing so it makes the different chains of \ndevelopment much harder to see. It also ends up showing the development in \na more \"parallel\" way, which in turn makes the view even harder to read.\n\nSo I would suggest not using --date-order by default. It doesn't add \nanything to any normal flow, and it makes the big picture harder to see.\n\nThe only time you really want --date-order (or \"-d\", which is shorthand \nfor it for just gitk) is really\n\n - when the big picture is really really simple, and you actually want to \n see more detail because the big picture is too trivial to even be \n interesting otherwise.\n\n (In other words: --date-order is fine for really simple development \n where there is only ever just a couple of branches or where you have \n pruned away so much of the history that the remaining part is simple)\n\n - when you want to debug \"git rev-list\" behaviour itself, since the date \n order actually matters for how git traverses the commit chains.\n\nThe second case is something that I suspect nobody but me and a few other \npeople have ever done. I found it very useful together with --show-all \nwhen I was debugging the revision walker (see commits\n\n\t3131b713013f06285cad3ffdcc61f417ac4ba158\n\t7d004199d134c9d465e013064f72dbc04507f6c0\n\nwhere the first implements --show-all, and the second one is the end \nresult of my debugging).\n\nIn other words: never start out with \"-d\" or \"--date-order\" by default. \nOnly if you have some reason to then think that the view is too simple or \nyou need to drill down into the commit relationships should you use it.\n\n> 1. what do you all do to get a high-level view of what's going on with Git\n> development? do you use gitk? if so, what options?\n\nI use \"gitk\" almost every time when I pull from anybody in the kernel. I \ntend to do it with git itself, when I update from Junio. The most common \narguments I use is\n\n\tgitk ORIG_HEAD..\n\nor\n\n\tgitk @{12.hours.ago}..\n\nwhere the latter in particular is very nice to see an overview of \"ok, \nwhat did I pull today\".\n\nAnd I basically *never* use --date-order, nor do I often look at more than \none single branch.\n\nThe one special case is when merging, and there are conflicts. In that \ncase, I often look at two branches, and I often do\n\n\tgitk MERGE_HEAD... \n\nto see the symmetric difference (actually, I usually just do \"gitk \n--merge\" which is just shorthand for the above). And in that case, I do \noccasionally add a \"-d\", because that shows what the relative timing were \nfor the commits, which is sometimes interesting information (ie if there \nare clashes, which commit is the more recently committed one can actually \nbe somewhat relevant - although it's rare).\n\nSo in that case I look at two branches (the one I'm on, and the one I'm \nmerging), and the \"...\" format means that I ignore everything that is \ncommon to them.\n\n> 2. as a project, why don't you rebase when merging long-running branches into\n> master?\n\nFor the kernel, there's been a lot of discussion about why I prefer people \nto rebase vs merge (or often - *avoiding* merges entirely), see the kernel \nmailing list, and search for merging. There was a thread (subject: \n\"[alsa-devel] HG -> GIT migration\") about a week ago where I tried to \nexplain my opinions about about some of this.\n\n\t\tLinus\n"},{"id":"77920","messageId":"m37ide3jtf.fsf@localhost.localdomain","threadId":"13677","inReplyTo":"alpine.LFD.1.10.0805271957430.2958@woody.linux-foundation.org","subject":"Re: visualizing Git's Git repo","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-05-28T08:39:16Z","receivedAt":"2008-05-28T08:39:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 26 May 2008, Joshua Haberman wrote:\n> >\n> > 2. as a project, why don't you rebase when merging long-running branches into\n> > master?\n> \n> For the kernel, there's been a lot of discussion about why I prefer people \n> to rebase vs merge (or often - *avoiding* merges entirely), see the kernel \n> mailing list, and search for merging. There was a thread (subject: \n> \"[alsa-devel] HG -> GIT migration\") about a week ago where I tried to \n> explain my opinions about about some of this.\n\nYou can read summary of this (I think) discussion at KernelTrap:\n http://kerneltrap.org/Linux/Git_Management\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}