{"thread":{"id":"5471","subject":"New git commit tool","startedAt":"2006-09-04T11:52:35Z","lastAt":"2006-09-05T16:46:52Z","messageCount":9,"participants":["Paul Mackerras","Jakub Narebski","Linus Torvalds","Jonas Fonseca","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26299","messageId":"17660.4995.977221.767112@cargo.ozlabs.ibm.com","threadId":"5471","inReplyTo":null,"subject":"New git commit tool","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-09-04T11:52:35Z","receivedAt":"2006-09-04T11:52:35Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"I have been working on a tool for creating commits, and I think it is\nnow far enough along to be useful.  I added it to the 'new' branch of\nmy gitk.git repository (git://git.kernel.org/pub/scm/gitk/gitk.git) or\nyou can fetch it from http://ozlabs.org/~paulus/gitool.\n\nThe way it works is that one \"checks in\" a set of changes, types a\nmessage into the lower pane, then clicks the \"Commit\" button to create\nthe commit.  When the commit has been created, the tool exits.\n\nThe changes that have been checked in are recorded in the index.\nGitool can also undo checkins, restoring the index state for a file to\nthe original state (i.e. the state in the current HEAD commit).\n\nAt the top, gitool displays two lists of filenames, with an icon\nbeside each name.  The left-hand list shows modified files (whether\nchecked in or not), and the right-hand list shows new files (those\njust added, and untracked files).  Clicking on the icon changes the\nstate of a file, alternating between not-checked-in and checked-in.\n\nClicking on the filename displays something useful; for a modified\nfile, it shows the changes made; for a new or untracked file, it shows\nthe contents of the file.\n\nFiles can also be partly checked in, for example, if changes were made\nand checked in, and then further changes were made.  Clicking on such\na file will show a 3-way diff (HEAD vs. checked-in state vs. working\nfile), provided Junio applies my patch to diff-lib.c. :)\n\nGitool doesn't handle merge commits yet, but that is something I want\nto implement soon, hopefully with the ability to resolve merge\nconflicts in the tool.  There are quite a few other features I want to\nimplement as well (key bindings, font size selection, persistent\ngeometry).\n\nComments and suggestions are welcome.  Patches are even more\nwelcome. :)\n\nPaul.\n\n-- \nVGER BF report: U 0.977306\n"},{"id":"26302","messageId":"edh615$7iu$1@sea.gmane.org","threadId":"5471","inReplyTo":"17660.4995.977221.767112@cargo.ozlabs.ibm.com","subject":"Re: New git commit tool","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-04T12:26:22Z","receivedAt":"2006-09-04T12:26:22Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Paul Mackerras wrote:\n[...]\n\nAdded preliminary entry to GitWiki\n  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gitool\n\nPlease, when adding new tool, announce it also in GitWiki...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n\n\n-- \nVGER BF report: U 0.98878\n"},{"id":"26310","messageId":"Pine.LNX.4.64.0609040952550.27779@g5.osdl.org","threadId":"5471","inReplyTo":"17660.4995.977221.767112@cargo.ozlabs.ibm.com","subject":"Re: New git commit tool","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-04T17:10:11Z","receivedAt":"2006-09-04T17:10:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 4 Sep 2006, Paul Mackerras wrote:\n> \n> Files can also be partly checked in, for example, if changes were made\n> and checked in, and then further changes were made.  Clicking on such\n> a file will show a 3-way diff (HEAD vs. checked-in state vs. working\n> file), provided Junio applies my patch to diff-lib.c. :)\n\nI like the feature, but not necessarily how it's been done. I see three \nproblems:\n\na) the three-way diff makes it hard to see what you would _actually_ check \n   in (if you use the index state), because it (by design, of course) \n   mixes in not just the data you check in, but also the current state.\n\nb) if you ever click the icon to mark the whole file for checkin, you've \n   now forever lost the old index state (ie it seems to do the equivalent \n   of \"git-update-index\" into the main index). So you can't recover from \n   mistakenly clicking on the icon.\n\nc) there's no way to exit gracefully without saving the changes you've \n   done (related to (b), but also something you might want to do \n   regardless of any half-way-updated index state).\n\nNow, the second and third problem are really one and the same, I guess. It \nall boils down to the fact that I think one reasonable usage-case is that \nyou ran out of time and had to do something else, and you have two cases: \nyou _want_ to start up the next time with the half-way done thing (ie \nyou've marked certain files for committing), or you decide that you would \nmuch prefer to restart from the beginning for next time around. Both are \nentirely valid cases, and right now your git commit tool makes it \nimpossible to do the latter.\n\nSo for problems (b)-(c), I _think_ the right answer is to do all the index \nwork in a new temporary copy of the index, and only on commit (or on \"quit \nand save current work\") do you actually write back to the old index file. \nThat way, you can also always re-read the original index file to get the \nprevious state..\n\nAs to (a) - I think it would in many ways be nicer if you could have some \nway to in addition to the three-way diff also show the regular two-way \ndiffs for\n\n (i) what would you actually commit\n (ii) what are the _additional_ changes there in that file\n\nwhich is what you'd normally want to see, I think. The three-way diff \nshows that, of course, but in a form that most people wouldn't understand, \nmethinks.\n\nI do have a fourth issue, which is that I hate \"gitool\" as a name. It \neither parses as \"gi\"+\"tool\", which makes no sense, or \"git\"+\"ool\", which \nalso makes no sense. \"gitk\" was cute, \"gitool\" is just irritating ;)\n\nThat said, it definitely has potential. \n\n\t\t\tLinus\n"},{"id":"26315","messageId":"20060904195736.GB2752@diku.dk","threadId":"5471","inReplyTo":"17660.4995.977221.767112@cargo.ozlabs.ibm.com","subject":"Re: New git commit tool","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-09-04T19:57:36Z","receivedAt":"2006-09-04T19:57:36Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Paul Mackerras <paulus@samba.org> wrote Mon, Sep 04, 2006:\n> Comments and suggestions are welcome.\n\nWhile doing my best to misuse gitool here is what happened ...\n\n 1. To try out gitool I did the following:\n\n\t$ mkdir gitool\n\t$ cd gitool\n\t$ git init-db\n\t$ wget http://ozlabs.org/~paulus/gitool\n\t$ git add gitool\n\n    Oops, forgot to make it executable ...\n\n\t$ chmod +x gitool\n\t$ ./gitool\n\n    I am a Cogito user, so I am no used to running git-update-index and\n    this seems to be a problem in this case:\n\n\tcan't unset \"indexpending(gitool)\": no such element in array\n\tcan't unset \"indexpending(gitool)\": no such element in array\n\t    while executing\n\t\"unset indexpending($f)\"\n\t    (procedure \"readfmod\" line 92)\n\t    invoked from within\n\t\"readfmod file11 0\"\n\n 2. When closing the window while the \"Application Error\" is still open\n    causes the following error:\n\n\tbgerror failed to handle background error.\n\t    Original error: can't unset \"indexpending(gitool)\": no such element in array\n\t    Error in bgerror: can't invoke \"grab\" command:  application has been destroyed\n\tbgerror failed to handle background error.\n\t    Original error: invalid command name \".ptop.comm.t\"\n\t    Error in bgerror: can't invoke \"tk\" command:  application has been destroyed\n\n    Maybe it should be ignored.\n\n 3. Finally, I find the difference between clicking on a file name\n    versus clicking on a file icon a bit strange. I continue on the\n    example above, first modifying gitool and then creating a new file,\n    so a file is listed both under \"Modified files\" and \"Untracked/new\n    files\".\n\n\t1. Click on the file name of the modified file to see the diff\n\t   in the content buffer.\n\n\t2. Click on the file icon of the untracked file to add it. State\n\t   shows \"Added\" and the content buffer is cleared.\n\n    I have to press the file name to see the content of the added file.\n    Maybe it should show the content regardless of whether the file name\n    or icon was pressed.\n\n-- \nJonas Fonseca\n"},{"id":"26318","messageId":"17660.39046.767944.582869@cargo.ozlabs.ibm.com","threadId":"5471","inReplyTo":"Pine.LNX.4.64.0609040952550.27779@g5.osdl.org","subject":"Re: New git commit tool","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-09-04T21:20:06Z","receivedAt":"2006-09-04T21:20:06Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Linus Torvalds writes:\n\n> I do have a fourth issue, which is that I hate \"gitool\" as a name. It \n> either parses as \"gi\"+\"tool\", which makes no sense, or \"git\"+\"ool\", which \n> also makes no sense. \"gitk\" was cute, \"gitool\" is just irritating ;)\n\nI was calling it \"gitt\" for a long time, which is at least shorter and\neasier to type.  I also thought of \"tick\" (anagram of tk + \"ci\" for\ncheck in), but maybe all that shows I've been doing too many cryptic\ncrosswords lately. :)  The \"gitool\" was by analogy with the \"citool\"\nof another system we've both used.  I'm happy to change it if someone\nhas a better idea...\n\nPaul.\n"},{"id":"26319","messageId":"Pine.LNX.4.64.0609041435311.27779@g5.osdl.org","threadId":"5471","inReplyTo":"17660.39046.767944.582869@cargo.ozlabs.ibm.com","subject":"Re: New git commit tool","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-09-04T21:40:16Z","receivedAt":"2006-09-04T21:40:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 5 Sep 2006, Paul Mackerras wrote:\n> \n> I was calling it \"gitt\" for a long time, which is at least shorter and\n> easier to type.  I also thought of \"tick\" (anagram of tk + \"ci\" for\n> check in), but maybe all that shows I've been doing too many cryptic\n> crosswords lately. :)  The \"gitool\" was by analogy with the \"citool\"\n> of another system we've both used.  I'm happy to change it if someone\n> has a better idea...\n\nI had kind of expected more of an integration with gitk, and just using \n\"gitk\" as the generic name for \"git tk interface\", it would perhaps make \nmore sense to just interface it that way, and thus one logical (?) thing \nto do would be to just make the command be\n\n\tgitk commit\n\nthe same way we have \"git commit\". Hmm?\n\nBut maybe I'm just strange.\n\n\t\tLinus\n"},{"id":"26321","messageId":"17660.40934.605502.248266@cargo.ozlabs.ibm.com","threadId":"5471","inReplyTo":"20060904195736.GB2752@diku.dk","subject":"Re: New git commit tool","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-09-04T21:51:34Z","receivedAt":"2006-09-04T21:51:34Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Jonas Fonseca writes:\n\n>     I am a Cogito user, so I am no used to running git-update-index and\n>     this seems to be a problem in this case:\n> \n> \tcan't unset \"indexpending(gitool)\": no such element in array\n\nHmmm, I didn't think that could happen. :) It can only happen if some\nfile gets listed twice in the output from \"git-diff-index HEAD\".\nCould you send me the output of \"git-diff-index HEAD\" and\n\"git-diff-index --cached HEAD\" in that repository?\n\nAnd no, you don't need to run git-update-index, gitool does that for\nyou.\n\nPaul.\n"},{"id":"26352","messageId":"20060905084546.GA30945@diana.vm.bytemark.co.uk","threadId":"5471","inReplyTo":"17660.39046.767944.582869@cargo.ozlabs.ibm.com","subject":"Re: New git commit tool","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-09-05T08:45:46Z","receivedAt":"2006-09-05T08:45:46Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-09-05 07:20:06 +1000, Paul Mackerras wrote:\n\n> I was calling it \"gitt\" for a long time, which is at least shorter\n> and easier to type. I also thought of \"tick\" (anagram of tk + \"ci\"\n> for check in), but maybe all that shows I've been doing too many\n> cryptic crosswords lately. :) The \"gitool\" was by analogy with the\n> \"citool\" of another system we've both used. I'm happy to change it\n> if someone has a better idea...\n\ngitci?\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"26364","messageId":"20060905164652.GB5547@diku.dk","threadId":"5471","inReplyTo":"17660.40934.605502.248266@cargo.ozlabs.ibm.com","subject":"Re: New git commit tool","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-09-05T16:46:52Z","receivedAt":"2006-09-05T16:46:52Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Paul Mackerras <paulus@samba.org> wrote Tue, Sep 05, 2006:\n> Jonas Fonseca writes:\n> \n> >     I am a Cogito user, so I am no used to running git-update-index and\n> >     this seems to be a problem in this case:\n> > \n> > \tcan't unset \"indexpending(gitool)\": no such element in array\n> \n> Hmmm, I didn't think that could happen. :) It can only happen if some\n> file gets listed twice in the output from \"git-diff-index HEAD\".\n> Could you send me the output of \"git-diff-index HEAD\" and\n> \"git-diff-index --cached HEAD\" in that repository?\n\n~/gitool > git-diff-index HEAD\nfatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.\nUse '--' to separate paths from revisions\n~/gitool > git-diff-index --cached HEAD\nfatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.\nUse '--' to separate paths from revisions\n~/gitool > cat .git/HEAD\nref: refs/heads/master\n~/gitool > ls .git/refs/heads/\n~/gitool >\n\n> And no, you don't need to run git-update-index, gitool does that for\n> you.\n\nGood to hear, but I swear the first time I ran gitool in a repo of mine\nit popped up the error dialog with the details saying:\n\n\tfileX: needs update\n\nNow, of course, I cannot reproduce it.\n\n-- \nJonas Fonseca\n"}]}