{"thread":{"id":"24478","subject":"rfc - Changing the way gitk and git-gui are managed","startedAt":"2010-07-23T02:39:11Z","lastAt":"2010-07-27T10:28:17Z","messageCount":18,"participants":["Junio C Hamano","Sverre Rabbelier","Avery Pennarun","Will Palmer","Greg Troxel","Nicolas Sebrecht","Jonathan Nieder","Sam Vilain","Jeff King","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"146040","messageId":"7vocdygbw0.fsf@alter.siamese.dyndns.org","threadId":"24478","inReplyTo":null,"subject":"rfc - Changing the way gitk and git-gui are managed","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-23T02:39:11Z","receivedAt":"2010-07-23T02:39:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Somebody off-list suggested removing gitk and git-gui directories from my\nrepository and I've been playing with the idea and kind of like the end\nresult.\n\nThe plan (I am not decided to buy into it yet, hence I am sending this\nrfc) is to:\n\n - remove gitk-git and git-gui directories;\n - add modules/gitk and modules/git-gui submodules;\n - teach the top-level Makefile about the new location of these two\n packages.\n\nSwitching from 1.7.2 to this tree will of course give you a tree without\ngitk and git-gui (nothing a simple \"git submodule init/update\" cannot\nfix), and switching back from there to 1.7.2 codebase needs manual removal\nof these two directories that will become leftover directories if you want\nto keep the superproject directory pristine clean, but other than that, I\ndo not see major downsides.\n\nI am wondering what people think. Especially distro people who download\nand package git may be heavily affected. I haven't adjusted the RPM spec\nfile or \"make dist\" target, so I cannot assess the damage to these people\nmyself yet.\n"},{"id":"146041","messageId":"AANLkTimdYfv-Z57iHD+YLfjKi66av5xmaC3JEMRNRw+Y@mail.gmail.com","threadId":"24478","inReplyTo":"7vocdygbw0.fsf@alter.siamese.dyndns.org","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-07-23T04:04:23Z","receivedAt":"2010-07-23T04:04:23Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Jul 22, 2010 at 21:39, Junio C Hamano wrote:\n> Somebody off-list suggested removing gitk and git-gui directories from my\n> repository and I've been playing with the idea and kind of like the end\n> result.\n\nThe neighboring thread [0] about git subtree seems highly relevant to\nthis decision. Avery, do you perhaps any additional insights wrt this\nparticular use case?\n\nI on one hand like that we're going to (finally) start dogfooding\nsubmodules, but after reading Avery's emails I feel unsure whether\nthat really is the right course of action...\n\n[0] http://thread.gmane.org/gmane.comp.version-control.git/151408\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"146042","messageId":"AANLkTin9kbMp5nOS=GaM2rX1w+y8vbzYfWunkSSeoPZg@mail.gmail.com","threadId":"24478","inReplyTo":"AANLkTimdYfv-Z57iHD+YLfjKi66av5xmaC3JEMRNRw+Y@mail.gmail.com","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-07-23T06:16:45Z","receivedAt":"2010-07-23T06:16:45Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Jul 23, 2010 at 12:04 AM, Sverre Rabbelier wrote:\n> On Thu, Jul 22, 2010 at 21:39, Junio C Hamano wrote:\n>> Somebody off-list suggested removing gitk and git-gui directories from my\n>> repository and I've been playing with the idea and kind of like the end\n>> result.\n>\n> The neighboring thread [0] about git subtree seems highly relevant to\n> this decision. Avery, do you perhaps any additional insights wrt this\n> particular use case?\n\nOnly this: Junio said that there are no major downsides to this change\n- and given the slow pace of change in gitk/git-gui, this is probably\ntrue - but are there any *upsides*? What problem does this solve?\n\ngit-submodule and git-subtree solve different problems, so which one\nis \"better\" depends on the problem to be solved. As a\nmostly-just-user of git, whatever is currently being done is super\nconvenient and easy for me and I wouldn't ask for any change at all.\nObviously it might be very different from Junio's point of view :)\n\nHave fun,\n\nAvery\n"},{"id":"146043","messageId":"1279868098.2846.45.camel@dreddbeard","threadId":"24478","inReplyTo":"7vocdygbw0.fsf@alter.siamese.dyndns.org","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Will Palmer","fromEmail":"wmpalmer@gmail.com","sentAt":"2010-07-23T06:54:58Z","receivedAt":"2010-07-23T06:54:58Z","isPatch":false,"sender":{"key":"wmpalmer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/357044?v=4"},"body":"On Thu, 2010-07-22 at 19:39 -0700, Junio C Hamano wrote:\n> Somebody off-list suggested removing gitk and git-gui directories from my\n> repository and I've been playing with the idea and kind of like the end\n> result.\n...snip...\n> \n> I am wondering what people think.\n...snip...\n\nI really like the idea of using submodules, though only so that they\nwill almost certainly get the UI attention they deserve. Indeed, in my\nmind that attention is needed enough that this sort of switch shouldn't\nbe made until it's been given for a while.\n\nThe problem is that, unlike so much of git, submodules make themselves\nknown. They're loud, they're in the way, they require management to\nwork. Case in point:\n\"Switching from 1.7.2 to this tree will of course give you a tree\nwithout gitk and git-gui (nothing a simple \"git submodule init/update\"\ncannot fix)\"\n\nSo already in order to build a working git again, someone needs to\nmanually run some extra commands, which could potentially (but not\nnecessarily) download a bunch of objects they already have. Basic\noperations like switching branches, get an extra (and easily overlooked)\nburden, to which there is sometimes no obvious solution Ouch.\n\nI've always hated how clunky and non-transparent submodules are. There\nare some serious issues which would need to be worked out in order to\nmake them more transparent (not the least of which is \"to be\ntransparent, where do you put the extra data, and when do you put it\nthere / when do you remove it?\". I do wish that these issues would get\nresolved, and it's hard to give them the attention they need because [I\nassume, like me] the people who don't like them simply avoid using\nsubmodules, as \"just track everything\" just sounds more like the git\nway.\n\nGit is simple. It's easy to understand because of some simple\nassumptions and definitions. Submodules are less-simple. There are a lot\nof edge-cases and a lot of not-so-edge cases which need to be looked out\nfor in order to make them sane. Handling the tricky-but-common cases by\nputting it on the user to always hand-hold the VCS is stupid and broken.\n\nWhat do people really want which a move to submodules would get them?\n - Sub-Projects can obviously be developed separately (no need to clone\nall of git in order to work on gitk, for example)\n - Merges that make more sense, since you don't need to pass special\n\"subtree\" options, all you need to do is update the commit which gitk\npoints to. This ignores that merges across the submodule/subtree\nboundary will not work, and similarly changes which span submodules have\nno way of being blamed or sanely merged.\n\nIt certainly doesn't help that whenever I think about \"how to fix\nsubmodules\", the more I think about them, the less I think they make any\nsense at all. [rant deleted]\n\nPut me down as: I've wanted to use submodules in the past, and I like\nthe idea of using them in the future, but I've yet to be at the point\nwhere I wanted to use submodules \"now\".\n\n-- \n-- Will\n"},{"id":"146106","messageId":"rmi1vauyplh.fsf@fnord.ir.bbn.com","threadId":"24478","inReplyTo":"7vocdygbw0.fsf@alter.siamese.dyndns.org","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Greg Troxel","fromEmail":"gdt@ir.bbn.com","sentAt":"2010-07-23T19:18:02Z","receivedAt":"2010-07-23T19:18:02Z","isPatch":false,"sender":{"key":"gdt@ir.bbn.com","avatar":null},"body":"\n The plan (I am not decided to buy into it yet, hence I am sending this\n rfc) is to:\n\n - remove gitk-git and git-gui directories;\n - add modules/gitk and modules/git-gui submodules;\n - teach the top-level Makefile about the new location of these two\n packages.\n\n Switching from 1.7.2 to this tree will of course give you a tree without\n gitk and git-gui (nothing a simple \"git submodule init/update\" cannot\n fix), and switching back from there to 1.7.2 codebase needs manual removal\n of these two directories that will become leftover directories if you want\n to keep the superproject directory pristine clean, but other than that, I\n do not see major downsides.\n\n I am wondering what people think. Especially distro people who download\n and package git may be heavily affected. I haven't adjusted the RPM spec\n file or \"make dist\" target, so I cannot assess the damage to these people\n myself yet.\n\n(I am perhaps going to be involved in maintaining the git package in pkgsrc.)\n\nIn general, the effort to update the package control files is basically\n5 minutes per release (to change version, test, and summarize release\nnotes) plus coping with structural changes in how the package builds and\nwhat it installs.\n\nPerhaps implicit in your mail above:\n\n create new distribution packages for gitk and git-gui. These would\n have their own autoconf setup, and be independent packages, depending\n on the base git package.\n\nAssuming that:\n\n From a packager viewpoint this is good. That would make it easier to\n have a base git package that doesn't depend on much, and then a gitk\n package that just has gitk, depending on what it needs to.\n\n (A problem with git now is that it depends on tcl. I gather Linux\n packaging systems tend to build everything with the full set of\n possible dependencies and then split it into separate binary packages.\n pkgsrc is more focused on source builds and thus we really don't want\n to have tcl installed if the user doesn't want the gui, and a side\n effect of this focus is the lack of support for split packages from\n one build.)\n\nIf you don't mean separate distribution tarballs, then could you explain\nhow the released tarballs would change structurally?\n\n\n\n"},{"id":"146147","messageId":"20100724110239.GA13067@vidovic","threadId":"24478","inReplyTo":"7vocdygbw0.fsf@alter.siamese.dyndns.org","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2010-07-24T11:02:39Z","receivedAt":"2010-07-24T11:02:39Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 22/07/10, Junio C Hamano wrote:\n\n> Somebody off-list suggested removing gitk and git-gui directories from my\n> repository and I've been playing with the idea and kind of like the end\n> result.\n\nWhat is the issue with the current status?\n\n> The plan (I am not decided to buy into it yet, hence I am sending this\n> rfc) is to:\n> \n> - remove gitk-git and git-gui directories;\n> - add modules/gitk and modules/git-gui submodules;\n> - teach the top-level Makefile about the new location of these two\n> packages.\n\nGoing this way, why would we want gitk and git-gui as submodules at all?\nThey are porcelain tools as many other not in git.git.\n\n-- \nNicolas Sebrecht\n"},{"id":"146165","messageId":"20100724125408.GA17481@burratino","threadId":"24478","inReplyTo":"20100724110239.GA13067@vidovic","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-24T12:54:08Z","receivedAt":"2010-07-24T12:54:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nicolas Sebrecht wrote:\n\n> What is the issue with the current status?\n\nHere is one:\n\n $ git log --oneline -SListbox.font -- gitk-git/gitk\n $ git log --oneline --follow -SListbox.font -- gitk-git/gitk\n 62ba514 Move gitk to its own subdirectory\n $ git log --oneline -SListbox.font -- gitk-git/gitk gitk\n 207ad7b gitk: Set the font for all listbox widgets\n $\n\n> Going this way, why would we want gitk and git-gui as submodules at all?\n\nIf we want to stop distributing them completely (though I am not\nconvinced that would be a good idea), then submodules would be a\ngood stopping point along the way to avoid changing the world too\nmuch at a time.\n\ngit archive hasn’t learned to do recursive archive yet; I think\nthe last murmurs of that topic were [1] and [2], though it would\nbe simple enough to use \"git archive\" more than once together\nwith \"tar rf\" to take care of it by hand in this case.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/107030\nwhich is a reroll of\nhttp://thread.gmane.org/gmane.comp.version-control.git/106788/focus=106787\n\n[2] http://thread.gmane.org/gmane.comp.version-control.git/106788/focus=106787\n"},{"id":"146166","messageId":"20100724125701.GA17634@burratino","threadId":"24478","inReplyTo":"20100724125408.GA17481@burratino","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-24T12:57:01Z","receivedAt":"2010-07-24T12:57:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> git archive hasn’t learned to do recursive archive yet; I think\n> the last murmurs of that topic were [1] and [2]\n[...]\n> [2] http://thread.gmane.org/gmane.comp.version-control.git/106788/focus=106787\n\nOperator error, sorry. That link should read\nhttp://thread.gmane.org/gmane.comp.version-control.git/140032\n\nGood night.\n"},{"id":"146167","messageId":"20100724140054.GB13067@vidovic","threadId":"24478","inReplyTo":"20100724125408.GA17481@burratino","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2010-07-24T14:00:54Z","receivedAt":"2010-07-24T14:00:54Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 24/07/10, Jonathan Nieder wrote:\n> Nicolas Sebrecht wrote:\n> \n> > What is the issue with the current status?\n> \n> Here is one:\n> \n> $ git log --oneline -SListbox.font -- gitk-git/gitk\n> $ git log --oneline --follow -SListbox.font -- gitk-git/gitk\n> 62ba514 Move gitk to its own subdirectory\n> $ git log --oneline -SListbox.font -- gitk-git/gitk gitk\n> 207ad7b gitk: Set the font for all listbox widgets\n> $\n\nI'm sorry, I don't get your point here.\n\n> > Going this way, why would we want gitk and git-gui as submodules at all?\n> \n> If we want to stop distributing them completely (though I am not\n> convinced that would be a good idea), then submodules would be a\n> good stopping point along the way to avoid changing the world too\n> much at a time.\n\nIt depends on why we would want to split gitk and git-gui from git. If\nit's a packaging issue only (especially for distribution maintainers),\ngoing by the \"submodule\" step looks more like adding a non-valuable\nextra step in the \"splitting packages\" mainstream.\n\nChanging the world once seems better than twice.\n\n> git archive hasn’t learned to do recursive archive yet; I think\n> the last murmurs of that topic were [1] and [2],\n\nI understand gitk and git-gui are in the Git repository mostly for\nhistorical reason. I don't want to hurt someone here but I still don't\nsee what both have so special against other porcelain tools not in\ngit.git.\n\n> though it would\n> be simple enough to use \"git archive\" more than once together\n> with \"tar rf\" to take care of it by hand in this case.\n\nSo, doing a tar archive of them all (with or whitout submodules) is not\nsuch an issue.\n\n-- \nNicolas Sebrecht\n"},{"id":"146199","messageId":"20100724172246.GA1714@burratino","threadId":"24478","inReplyTo":"20100724140054.GB13067@vidovic","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-24T17:22:46Z","receivedAt":"2010-07-24T17:22:46Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nicolas Sebrecht wrote:\n> The 24/07/10, Jonathan Nieder wrote:\n>> Nicolas Sebrecht wrote:\n\n>>> What is the issue with the current status?\n>>\n>> Here is one:\n>>\n>> $ git log --oneline -SListbox.font -- gitk-git/gitk\n>> $ git log --oneline --follow -SListbox.font -- gitk-git/gitk\n>> 62ba514 Move gitk to its own subdirectory\n>> $ git log --oneline -SListbox.font -- gitk-git/gitk gitk\n>> 207ad7b gitk: Set the font for all listbox widgets\n>> $\n>\n> I'm sorry, I don't get your point here.\n\nIf a person tries to drill into history to figure out the answer to a\nquestion like \"when was that code involving Listbox.font added\", it is\ntotally counterintuitive how to do that now.\n\nI run into this with git.git very often (you would think I would\nlearn).\n\nI don’t have any argument with the rest of what you have said. I\nprobably did not make it clear enough that I was not trying to\nadvocate for one side, only presenting pertinent information.\n\nRegards,\nJonathan\n"},{"id":"146200","messageId":"AANLkTi=R2-=TNXyFq4OCo6LsYOMNgVga+=6QrAfCoHRx@mail.gmail.com","threadId":"24478","inReplyTo":"20100724125408.GA17481@burratino","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-07-24T19:18:09Z","receivedAt":"2010-07-24T19:18:09Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Sat, Jul 24, 2010 at 8:54 AM, Jonathan Nieder wrote:\n> Nicolas Sebrecht wrote:\n>> What is the issue with the current status?\n>\n> Here is one:\n>\n>  $ git log --oneline -SListbox.font -- gitk-git/gitk\n>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk\n>  62ba514 Move gitk to its own subdirectory\n>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk\n>  207ad7b gitk: Set the font for all listbox widgets\n>  $\n\nThis is a bug in git log --follow, not a reason to completely redesign the repo.\n\nFWIW, I previously tracked the bug down to the fact that it doesn't\ntrack file renames that happen during a merge commit, which is what\nsubtree merge produces. I don't have the time or knowledge required\nto fix it.\n\nHave fun,\n\nAvery\n"},{"id":"146201","messageId":"20100724193428.GA4491@burratino","threadId":"24478","inReplyTo":"AANLkTi=R2-=TNXyFq4OCo6LsYOMNgVga+=6QrAfCoHRx@mail.gmail.com","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-24T19:34:28Z","receivedAt":"2010-07-24T19:34:28Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Avery Pennarun wrote:\n> On Sat, Jul 24, 2010 at 8:54 AM, Jonathan Nieder wrote:\n\n>>  $ git log --oneline -SListbox.font -- gitk-git/gitk\n>>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk\n>>  62ba514 Move gitk to its own subdirectory\n>>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk\n>>  207ad7b gitk: Set the font for all listbox widgets\n>>  $\n>\n> This is a bug in git log --follow\n\nThe first one is not.\n\n> FWIW, I previously tracked the bug down to the fact that it doesn't\n> track file renames that happen during a merge commit, which is what\n> subtree merge produces. I don't have the time or knowledge required\n> to fix it.\n\nAnother pointer for interested people:\n\n http://thread.gmane.org/gmane.comp.version-control.git/150727/focus=150796\n\nI prefer to work without --follow, anyway. :)\n\nHope that helps,\nJonathan\n"},{"id":"146243","messageId":"AANLkTikkMYY5r4RzBZ-mTBVSXuZfhu8HSZPEbNTGnJ2i@mail.gmail.com","threadId":"24478","inReplyTo":"20100724193428.GA4491@burratino","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-07-25T04:11:37Z","receivedAt":"2010-07-25T04:11:37Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Sat, Jul 24, 2010 at 3:34 PM, Jonathan Nieder wrote:\n> Avery Pennarun wrote:\n>> On Sat, Jul 24, 2010 at 8:54 AM, Jonathan Nieder wrote:\n>\n>>>  $ git log --oneline -SListbox.font -- gitk-git/gitk\n>>>  $ git log --oneline --follow -SListbox.font -- gitk-git/gitk\n>>>  62ba514 Move gitk to its own subdirectory\n>>>  $ git log --oneline -SListbox.font -- gitk-git/gitk gitk\n>>>  207ad7b gitk: Set the font for all listbox widgets\n>>>  $\n>>\n>> This is a bug in git log --follow\n>\n> The first one is not.\n\nThat one is a bug in history simplification, which has simplified away\ncommits that affected files that got renamed into gitk-git/gitk during\na merge commit. So the bug is very similar, albeit probably in a\ndifferent place in the code. (-M doesn't help either.)\n\nAvery\n"},{"id":"146293","messageId":"1280054644.2196.38.camel@arcturus","threadId":"24478","inReplyTo":"1279868098.2846.45.camel@dreddbeard","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2010-07-25T10:44:04Z","receivedAt":"2010-07-25T10:44:04Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Fri, 2010-07-23 at 07:54 +0100, Will Palmer wrote:\n> The problem is that, unlike so much of git, submodules make themselves\n> known. They're loud, they're in the way, they require management to\n> work. Case in point:\n> \"Switching from 1.7.2 to this tree will of course give you a tree\n> without gitk and git-gui (nothing a simple \"git submodule init/update\"\n> cannot fix)\"\n> \n> So already in order to build a working git again, someone needs to\n> manually run some extra commands, which could potentially (but not\n [...]\n\nThere's a relatively comprehensive list of TODO items on the git wiki\nalong with the summer of code ideas page. They have been known for some\ntime, but up till now most people have just worked around them. I think\nusing it for git-core would possibly assist in creating the anger that\nsome of these changes will need to be performed in to be of greater\nbenefit to the community as a whole ;-)\n\nsubmodules are nice; it's good for instance to be able to keep unrelated\nparts of the project out of the history view, squashed in the main\nproject yet still fine-grained and bisectable in the sub-project. While\nI haven't gone through the other people who have described their use\ncases/requirements in detail, it strikes me that many of the existing\nideas would help these requirements be met too.\n\nSam\n"},{"id":"146446","messageId":"20100727053040.GA6014@coredump.intra.peff.net","threadId":"24478","inReplyTo":"AANLkTin9kbMp5nOS=GaM2rX1w+y8vbzYfWunkSSeoPZg@mail.gmail.com","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-07-27T05:30:40Z","receivedAt":"2010-07-27T05:30:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:\n\n> Only this: Junio said that there are no major downsides to this change\n> - and given the slow pace of change in gitk/git-gui, this is probably\n> true - but are there any *upsides*? What problem does this solve?\n\nOne minor complaint with the current setup is that browsing the history\nwith path limiting is unintuitive. You can't do \"gitk gitk\" in the\ngitk-git directory. You must instead do \"cd .. && gitk -- gitk\".\n\n-Peff\n"},{"id":"146449","messageId":"AANLkTin+jUB85Zua7TP_dmdU9QSEiAuTDZhPQQ7hQTP-@mail.gmail.com","threadId":"24478","inReplyTo":"20100727053040.GA6014@coredump.intra.peff.net","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-07-27T05:42:39Z","receivedAt":"2010-07-27T05:42:39Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Jul 27, 2010 at 1:30 AM, Jeff King wrote:\n> On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:\n>> Only this: Junio said that there are no major downsides to this change\n>> - and given the slow pace of change in gitk/git-gui, this is probably\n>> true - but are there any *upsides*?  What problem does this solve?\n>\n> One minor complaint with the current setup is that browsing the history\n> with path limiting is unintuitive. You can't do \"gitk gitk\" in the\n> gitk-git directory. You must instead do \"cd .. && gitk -- gitk\".\n\nArguably this would be an encouragement to fix the path limiting code,\nin a similar way that people expect switching to a submodule setup to\nencourage people to fix submodules :)\n\nHave fun,\n\nAvery\n"},{"id":"146450","messageId":"20100727054638.GA6662@coredump.intra.peff.net","threadId":"24478","inReplyTo":"AANLkTin+jUB85Zua7TP_dmdU9QSEiAuTDZhPQQ7hQTP-@mail.gmail.com","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-07-27T05:46:38Z","receivedAt":"2010-07-27T05:46:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 27, 2010 at 01:42:39AM -0400, Avery Pennarun wrote:\n\n> On Tue, Jul 27, 2010 at 1:30 AM, Jeff King wrote:\n> > On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:\n> >> Only this: Junio said that there are no major downsides to this change\n> >> - and given the slow pace of change in gitk/git-gui, this is probably\n> >> true - but are there any *upsides*?  What problem does this solve?\n> >\n> > One minor complaint with the current setup is that browsing the history\n> > with path limiting is unintuitive. You can't do \"gitk gitk\" in the\n> > gitk-git directory. You must instead do \"cd .. && gitk -- gitk\".\n> \n> Arguably this would be an encouragement to fix the path limiting code,\n> in a similar way that people expect switching to a submodule setup to\n> encourage people to fix submodules :)\n\nHeh. Somewhat true. My multi-file --follow code actually handles \"git\nlog --follow gitk-git\", but it does look awful in gitk. And that is not\nlikely to be fixed soon, as --follow and things like parent rewriting\nsimply don't work together at this point.\n\n-Peff\n"},{"id":"146465","messageId":"m3k4ohkyns.fsf@localhost.localdomain","threadId":"24478","inReplyTo":"20100727053040.GA6014@coredump.intra.peff.net","subject":"Re: rfc - Changing the way gitk and git-gui are managed","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-07-27T10:28:17Z","receivedAt":"2010-07-27T10:28:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King writes:\n\n> On Fri, Jul 23, 2010 at 02:16:45AM -0400, Avery Pennarun wrote:\n> \n> > Only this: Junio said that there are no major downsides to this change\n> > - and given the slow pace of change in gitk/git-gui, this is probably\n> > true - but are there any *upsides*? What problem does this solve?\n> \n> One minor complaint with the current setup is that browsing the history\n> with path limiting is unintuitive. You can't do \"gitk gitk\" in the\n> gitk-git directory. You must instead do \"cd .. && gitk -- gitk\".\n\nDo 'gitk --relative=gitk' or 'gitk --relative' work?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}