{"thread":{"id":"6765","subject":"Merge git-gui into 1.5.0 ?","startedAt":"2007-02-11T08:40:30Z","lastAt":"2007-02-13T00:38:15Z","messageCount":24,"participants":["Shawn O. Pearce","Mark Levedahl","Johannes Schindelin","Junio C Hamano","Michael S. Tsirkin","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"34158","messageId":"20070211084030.GE2082@spearce.org","threadId":"6765","inReplyTo":null,"subject":"Merge git-gui into 1.5.0 ?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-11T08:40:30Z","receivedAt":"2007-02-11T08:40:30Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"One of my goals for git-gui is to get it merged into core Git, so\nthere is a GUI tool available out-of-the-box for commit creation,\n(some) branch manipulation, basic merging, and pushing/fetching\nchanges.\n\nI'm wondering, should that start to occur as part of 1.5.0?\nIts one .sh script, like gitk. :)\n\nGiven all of the other changes going into 1.5.0, and how much news\nwe're probably going to try to attract to this release, it may be\nnice to be able to say \"we also have a commit creating GUI\".\n\n\nThe main idea behind git-gui is to provide a complete enough UI\nthat someone can work on files stored in a Git repository without\nneeding to drop to the command line. By sticking to Tcl/Tk,\ngit-gui is available anywhere gitk is.\n\nIt would be nice if all operations available on the command line\nwere also available through git-gui, but I think that is a very\ndifficult goal to reach. The command line interface is simply more\npowerful and much more expressive. So I'm really just aiming to\nmake an interface that the average user can use to do collaboration\nthrough Git, without needing to fall back on git-cvsserver and a\nCVS client. I fully expect 'power' users to use the command line.\nYou know who you are. ;-)\n\nThat said, operations like `git gui blame rev file` may simply\nbe better in the GUI, even for power users, as it offers some way\nto visualize the annotation data and navigate through it. So I'm\nalso trying to make those parts of git-gui easily available from\nthe command line, when possible.\n\nAnother example is `git gui citool` (or `git citool` if git-citool\nis a symlink/hardlink to git-gui), which will open the UI for\njust one commit. Users of that-other-SCM-used-before-Git's citool\nsubcommand may like this feature, as it offers somewhat similiar\nfunctionality, and some nice extras. ;-)\n\n\nRight now git-gui is being used in production by myself and about 5\nother coworkers of mine (the rest were either die-hard command line\nusers already, or found out how useful the command line is and now\nrefuse to give it up!). It has thus far proven to be pretty stable\nand easy to use. Its running stably on both Mac OS X and Windows.\n\nIt is also lacking the critical `git clone` operation. ;-)\n\n\nThoughts? Anyone interested can check out the repository:\n\n gitweb: http://repo.or.cz/w/git-gui.git\n git: git://repo.or.cz/git-gui.git\n\n-- \nShawn.\n"},{"id":"34166","messageId":"45CF2EBC.8070107@verizon.net","threadId":"6765","inReplyTo":"20070211084030.GE2082@spearce.org","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Mark Levedahl","fromEmail":"mdl123@verizon.net","sentAt":"2007-02-11T14:57:00Z","receivedAt":"2007-02-11T14:57:00Z","isPatch":false,"sender":{"key":"mdl123@verizon.net","avatar":"https://avatars.githubusercontent.com/u/5302462?v=4"},"body":"Shawn O. Pearce wrote:\n> One of my goals for git-gui is to get it merged into core Git, so\n> there is a GUI tool available out-of-the-box for commit creation,\n> (some) branch manipulation, basic merging, and pushing/fetching\n> changes.\n> \n> I'm wondering, should that start to occur as part of 1.5.0?\n> Its one .sh script, like gitk. :)\n> \n\nI have recently moved a project involving multiple companies developing \non Windows and Linux from cvs(nt) over to git. The availability of \ngit-gui at the time was an important point: many folks working this \nproject simply will not work at the command line. We are still spinning \nup on git, but several of the developers are relying upon git-gui now \nand I expect that most will use it. So, I am definitely for moving \ngit-gui into git. It definitely fits well with the 1.5 usability theme.\n\nSide note: with my gitk fix for Cygwin now in master, git-gui should not \nbe deleting ~/.gitk on Cygwin anymore.\n\nWhatever the decision: Shawn - thank you for developing this.\n\nMark Levedahl\n"},{"id":"34173","messageId":"Pine.LNX.4.63.0702111738240.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6765","inReplyTo":"20070211084030.GE2082@spearce.org","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-11T16:39:52Z","receivedAt":"2007-02-11T16:39:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Feb 2007, Shawn O. Pearce wrote:\n\n> I'm wondering, should that start to occur as part of 1.5.0? Its one .sh \n> script, like gitk. :)\n\nIt really does not touch a core part of git, but adds value. Given that we \nalready include gitk, and that git-gui apparently got quite some testing, \nI am all for it.\n\nCiao,\nDscho\n"},{"id":"34196","messageId":"7vwt2oba8s.fsf@assigned-by-dhcp.cox.net","threadId":"6765","inReplyTo":"20070211084030.GE2082@spearce.org","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-11T22:27:47Z","receivedAt":"2007-02-11T22:27:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> One of my goals for git-gui is to get it merged into core Git, so\n> there is a GUI tool available out-of-the-box for commit creation,\n> (some) branch manipulation, basic merging, and pushing/fetching\n> changes.\n\nI do not have objection per-se, but I have two choices on the\nprocedure, and I hate having choices this close to the final\nrelease ;-).\n\n(1) I can do the usual 'no common ancestor' merge, and treat it\n just like gitk. I would probably place git-gui as a\n subdirectory in git.git (just like I did to gitweb/), and\n tweak the main Makefile to chdir down to git-gui, and let\n the git-gui/Makefile (the toplevel Makefile from your point\n of view) do its work. Your current git-gui repository that\n does not have rest of git.git will _remain_ git-less. In\n addition, git-gui repository remains to be the authoritative\n place its improvements take place. git.git pull from there\n from time to time to get updates.\n\n(2) After the 'no common ancestor' merge above, you fast forward\n git-gui to git.git and two repositories can cross pull from\n each other from that point on.\n\nI have a suspicion that doing the former may turn out to be a\ngood demonstration that git supports subprojects already. The\ntoplevel project _knows_ about subproject, but the subproject\ndoes not have to be aware of the toplevel project. Granted, the\ntoplevel project knows which specific version of the subproject\nis bound to each of its commit, which is tighter integration\nthan what usually is desired, but still it is a form of\nsubproject support that may be useful.\n\nI was actually hoping I can do so with Kay, but from his point\nof view merging gitweb to git.git was so that he does not have\nto worry about it anymore, so it did not work well.\n"},{"id":"34199","messageId":"20070211224158.GA31488@spearce.org","threadId":"6765","inReplyTo":"7vwt2oba8s.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-11T22:41:58Z","receivedAt":"2007-02-11T22:41:58Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> I do not have objection per-se, but I have two choices on the\n> procedure, and I hate having choices this close to the final\n> release ;-).\n...\n> I was actually hoping I can do so with Kay, but from his point\n> of view merging gitweb to git.git was so that he does not have\n> to worry about it anymore, so it did not work well.\n\nI'm OK with either approach here.\n\nOriginally I had intended to wipe out everything except git-gui.sh,\nthen do an ancestor-less merge into git.git's top level directory,\nand finally tweak git.git's master Makefile to add git-gui.sh to\nthe list of known shell scripts. Then I was going to ask you to\npull that resulting tree.\n\nBut it may make a *lot* more sense to treat is a true subproject in\nits own directory. Unlike Kay, I'm not looking to merge git-gui\ninto git.git to abandon it. I just think we should offer a GUI\nout of the box, git-gui has the same dependencies as gitk, and I\nhappen to like git-gui. ;-)\n\ngit-gui development is going to continue past 1.5.0's release.\nThere are still a lot of operations it should support that it\ncurrently does not do, and there are certainly user interface\nimprovements that can still be made.\n\nIt may be saner for all involved if that development happens in\nthe git-gui.git repository, with drops made to git.git by way of\nmerging the \"subproject\" every so often.\n\nIt may make patching slightly more interesting though, as some\nusers new to git-gui development may generate a patch in git.git\n(using a/git-gui/git-gui.sh as the path) which then would not apply\nas-is to the master git-gui development tree.\n\nEntirely your call Junio.\n\n-- \nShawn.\n"},{"id":"34200","messageId":"20070211224942.GB31488@spearce.org","threadId":"6765","inReplyTo":"45CF2EBC.8070107@verizon.net","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-11T22:49:42Z","receivedAt":"2007-02-11T22:49:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Mark Levedahl wrote:\n> I have recently moved a project involving multiple companies developing \n> on Windows and Linux from cvs(nt) over to git. The availability of \n> git-gui at the time was an important point: many folks working this \n> project simply will not work at the command line. We are still spinning \n> up on git, but several of the developers are relying upon git-gui now \n> and I expect that most will use it. So, I am definitely for moving \n> git-gui into git. It definitely fits well with the 1.5 usability theme.\n\nI'm glad git-gui has helped you migrate a team away from CVS.\nThe case you are describing is definately one of the reasons for\ncreating git-gui.\n\n> Side note: with my gitk fix for Cygwin now in master, git-gui should not \n> be deleting ~/.gitk on Cygwin anymore.\n\nGah. I forgot about that feature of git-gui. It is now removed,\nand a new version has been pushed out. Thank you for the reminder!\n \n> Whatever the decision: Shawn - thank you for developing this.\n\nYou are most welecome. :)\n\nPaul Mackerras deserves some credit too, as his prototype gitool\nwas the original insipiration behind git-gui. And his icons are\nstill in use within git-gui.\n\n-- \nShawn.\n"},{"id":"34202","messageId":"Pine.LNX.4.63.0702112351270.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6765","inReplyTo":"20070211224158.GA31488@spearce.org","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-11T22:53:39Z","receivedAt":"2007-02-11T22:53:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Feb 2007, Shawn O. Pearce wrote:\n\n> Unlike Kay, I'm not looking to merge git-gui into git.git to abandon it.\n\nThat's great!\n\n> It may be saner for all involved if that development happens in the \n> git-gui.git repository, with drops made to git.git by way of merging the \n> \"subproject\" every so often.\n\nFully agree.\n\n> It may make patching slightly more interesting though, as some\n> users new to git-gui development may generate a patch in git.git\n> (using a/git-gui/git-gui.sh as the path) which then would not apply\n> as-is to the master git-gui development tree.\n\nIn this case, a \"-p \" option to git-am would make sense, no?\n\nCiao,\nDscho\n"},{"id":"34204","messageId":"20070211230204.GE31488@spearce.org","threadId":"6765","inReplyTo":"Pine.LNX.4.63.0702112351270.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-11T23:02:04Z","receivedAt":"2007-02-11T23:02:04Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> > It may make patching slightly more interesting though, as some\n> > users new to git-gui development may generate a patch in git.git\n> > (using a/git-gui/git-gui.sh as the path) which then would not apply\n> > as-is to the master git-gui development tree.\n> \n> In this case, a \"-p \" option to git-am would make sense, no?\n\nAre you saying we just suddenly found a vaild use for a flag which\nnobody (except the original submitter) thought was useful? ;-)\n\nYes, clearly a -p on git-am would solve the problem quite nicely.\n\n-- \nShawn.\n"},{"id":"34208","messageId":"Pine.LNX.4.63.0702120025180.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6765","inReplyTo":"20070211230204.GE31488@spearce.org","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-11T23:25:55Z","receivedAt":"2007-02-11T23:25:55Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Feb 2007, Shawn O. Pearce wrote:\n\n> Johannes Schindelin wrote:\n> > > It may make patching slightly more interesting though, as some\n> > > users new to git-gui development may generate a patch in git.git\n> > > (using a/git-gui/git-gui.sh as the path) which then would not apply\n> > > as-is to the master git-gui development tree.\n> > \n> > In this case, a \"-p \" option to git-am would make sense, no?\n> \n> Are you saying we just suddenly found a vaild use for a flag which\n> nobody (except the original submitter) thought was useful? ;-)\n\nThat was my plan. But I was too lazy to look up the original poster...\n\nCiao,\nDscho\n"},{"id":"34249","messageId":"20070212054018.GC28231@mellanox.co.il","threadId":"6765","inReplyTo":"20070211230204.GE31488@spearce.org","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-12T05:40:18Z","receivedAt":"2007-02-12T05:40:18Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Shawn O. Pearce :\n> Subject: Re: Merge git-gui into 1.5.0 ?\n> \n> Johannes Schindelin wrote:\n> > > It may make patching slightly more interesting though, as some\n> > > users new to git-gui development may generate a patch in git.git\n> > > (using a/git-gui/git-gui.sh as the path) which then would not apply\n> > > as-is to the master git-gui development tree.\n> > \n> > In this case, a \"-p \" option to git-am would make sense, no?\n> \n> Are you saying we just suddenly found a vaild use for a flag which\n> nobody (except the original submitter) thought was useful? ;-)\n> \n> Yes, clearly a -p on git-am would solve the problem quite nicely.\n\nActually, -p option to git-am is also useful for piping\npatches to git-am directly from mail: sometimes people would generate\na patch by hand and this results in patches incorrect -p level.\n\t\n-- \nMST\n"},{"id":"34250","messageId":"7vvei89b9k.fsf@assigned-by-dhcp.cox.net","threadId":"6765","inReplyTo":"20070212054018.GC28231@mellanox.co.il","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-12T05:48:39Z","receivedAt":"2007-02-12T05:48:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> Actually, -p option to git-am is also useful for piping\n> patches to git-am directly from mail: sometimes people would generate\n> a patch by hand and this results in patches incorrect -p level.\n\nYou also would need negative -p option to deal with it as well.\nThink of getting \"diff a/git-add.txt b/git-add.txt\" and wanting\nto apply it to Documentation/git-add.txt.\n\n \n"},{"id":"34252","messageId":"20070212055903.GD28231@mellanox.co.il","threadId":"6765","inReplyTo":"7vvei89b9k.fsf@assigned-by-dhcp.cox.net","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-12T05:59:03Z","receivedAt":"2007-02-12T05:59:03Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Junio C Hamano :\n> Subject: Re: Merge git-gui into 1.5.0 ?\n> \n> \"Michael S. Tsirkin\" writes:\n> \n> > Actually, -p option to git-am is also useful for piping\n> > patches to git-am directly from mail: sometimes people would generate\n> > a patch by hand and this results in patches incorrect -p level.\n> \n> You also would need negative -p option to deal with it as well.\n> Think of getting \"diff a/git-add.txt b/git-add.txt\" and wanting\n> to apply it to Documentation/git-add.txt.\n\nHeh, right. With patch I just switch to another shell, cd to the correct\ndirectory, start mutt *there* and pipe the message to patch. Since this already\nseems to work for git-apply, maybe this can be made to work with git-am as well?\n\nCurrently:\n$git-am mbox\nfatal: Not a git repository: '.git'\nYou need to run this command from the toplevel of the working tree.\n\n-- \nMST\n"},{"id":"34257","messageId":"20070212062529.GE28231@mellanox.co.il","threadId":"6765","inReplyTo":"20070212055903.GD28231@mellanox.co.il","subject":"Re: Merge git-gui into 1.5.0 ?","fromName":"Michael S. Tsirkin","fromEmail":"mst@mellanox.co.il","sentAt":"2007-02-12T06:25:29Z","receivedAt":"2007-02-12T06:25:29Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Michael S. Tsirkin :\n> Subject: Re: Merge git-gui into 1.5.0 ?\n> \n> > Quoting Junio C Hamano :\n> > Subject: Re: Merge git-gui into 1.5.0 ?\n> > \n> > \"Michael S. Tsirkin\" writes:\n> > \n> > > Actually, -p option to git-am is also useful for piping\n> > > patches to git-am directly from mail: sometimes people would generate\n> > > a patch by hand and this results in patches incorrect -p level.\n> > \n> > You also would need negative -p option to deal with it as well.\n> > Think of getting \"diff a/git-add.txt b/git-add.txt\" and wanting\n> > to apply it to Documentation/git-add.txt.\n> \n> Heh, right. With patch I just switch to another shell, cd to the correct\n> directory, start mutt *there* and pipe the message to patch. Since this already\n> seems to work for git-apply, maybe this can be made to work with git-am as well?\n> \n> Currently:\n> $git-am mbox\n> fatal: Not a git repository: '.git'\n> You need to run this command from the toplevel of the working tree.\n\nJunio, the following seems to work for me. Is this correct?\nIf yes, adding -p is trivial.\n\nMake git-am support \"negative strip-level\" patches by running it\nin a subdirectory.\n\nSigned-off-by: Michael S. Tsirkin \n\n---\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 9a61234..4cea1d2 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -5,6 +5,8 @@\n USAGE='[--signoff] [--dotest=] [--utf8 | --no-utf8] [--binary] [--3way]\n [--interactive] [--whitespace=