New git commit tool

I have been working on a tool for creating commits, and I think it is now far enough along to be useful. I added it to the 'new' branch of my gitk.git repository (git://git.kernel.org/pub/scm/gitk/gitk.git) or you can fetch it from http://ozlabs.org/~paulus/gitool.

The way it works is that one "checks in" a set of changes, types a message into the lower pane, then clicks the "Commit" button to create the commit. When the commit has been created, the tool exits.

The changes that have been checked in are recorded in the index. Gitool can also undo checkins, restoring the index state for a file to the original state (i.e. the state in the current HEAD commit).

At the top, gitool displays two lists of filenames, with an icon beside each name. The left-hand list shows modified files (whether checked in or not), and the right-hand list shows new files (those just added, and untracked files). Clicking on the icon changes the state of a file, alternating between not-checked-in and checked-in.

Clicking on the filename displays something useful; for a modified file, it shows the changes made; for a new or untracked file, it shows the contents of the file.

Files can also be partly checked in, for example, if changes were made and checked in, and then further changes were made. Clicking on such a file will show a 3-way diff (HEAD vs. checked-in state vs. working file), provided Junio applies my patch to diff-lib.c. :)

Gitool doesn't handle merge commits yet, but that is something I want to implement soon, hopefully with the ability to resolve merge conflicts in the tool. There are quite a few other features I want to implement as well (key bindings, font size selection, persistent geometry).

Comments and suggestions are welcome. Patches are even more welcome. :)

Paul.

Paul Mackerras wrote: [...]

Added preliminary entry to GitWiki
  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gitool

Please, when adding new tool, announce it also in GitWiki...

On Mon, 4 Sep 2006, Paul Mackerras wrote:

I like the feature, but not necessarily how it's been done. I see three problems:

a) the three-way diff makes it hard to see what you would _actually_ check 
   in (if you use the index state), because it (by design, of course) 
   mixes in not just the data you check in, but also the current state.

b) if you ever click the icon to mark the whole file for checkin, you've 
   now forever lost the old index state (ie it seems to do the equivalent 
   of "git-update-index" into the main index). So you can't recover from 
   mistakenly clicking on the icon.

c) there's no way to exit gracefully without saving the changes you've 
   done (related to (b), but also something you might want to do 
   regardless of any half-way-updated index state).

Now, the second and third problem are really one and the same, I guess. It all boils down to the fact that I think one reasonable usage-case is that you ran out of time and had to do something else, and you have two cases: you _want_ to start up the next time with the half-way done thing (ie you've marked certain files for committing), or you decide that you would much prefer to restart from the beginning for next time around. Both are entirely valid cases, and right now your git commit tool makes it impossible to do the latter.

So for problems (b)-(c), I _think_ the right answer is to do all the index work in a new temporary copy of the index, and only on commit (or on "quit and save current work") do you actually write back to the old index file. That way, you can also always re-read the original index file to get the previous state..

As to (a) - I think it would in many ways be nicer if you could have some way to in addition to the three-way diff also show the regular two-way diffs for

 (i) what would you actually commit
 (ii) what are the _additional_ changes there in that file

which is what you'd normally want to see, I think. The three-way diff shows that, of course, but in a form that most people wouldn't understand, methinks.

I do have a fourth issue, which is that I hate "gitool" as a name. It either parses as "gi"+"tool", which makes no sense, or "git"+"ool", which also makes no sense. "gitk" was cute, "gitool" is just irritating ;)

That said, it definitely has potential. 

			Linus

Linus Torvalds writes:

I was calling it "gitt" for a long time, which is at least shorter and easier to type. I also thought of "tick" (anagram of tk + "ci" for check in), but maybe all that shows I've been doing too many cryptic crosswords lately. :) The "gitool" was by analogy with the "citool" of another system we've both used. I'm happy to change it if someone has a better idea...

Paul.

On Tue, 5 Sep 2006, Paul Mackerras wrote:

I had kind of expected more of an integration with gitk, and just using "gitk" as the generic name for "git tk interface", it would perhaps make more sense to just interface it that way, and thus one logical (?) thing to do would be to just make the command be

	gitk commit

the same way we have "git commit". Hmm?

But maybe I'm just strange.

		Linus

On 2006-09-05 07:20:06 +1000, Paul Mackerras wrote:

gitci?

Paul Mackerras <paulus@samba.org> wrote Mon, Sep 04, 2006:

While doing my best to misuse gitool here is what happened ...

 1. To try out gitool I did the following:

	$ mkdir gitool
	$ cd gitool
	$ git init-db
	$ wget http://ozlabs.org/~paulus/gitool
	$ git add gitool

    Oops, forgot to make it executable ...

	$ chmod +x gitool
	$ ./gitool

    I am a Cogito user, so I am no used to running git-update-index and
    this seems to be a problem in this case:

	can't unset "indexpending(gitool)": no such element in array
	can't unset "indexpending(gitool)": no such element in array
	    while executing
	"unset indexpending($f)"
	    (procedure "readfmod" line 92)
	    invoked from within
	"readfmod file11 0"

 2. When closing the window while the "Application Error" is still open
    causes the following error:

	bgerror failed to handle background error.
	    Original error: can't unset "indexpending(gitool)": no such element in array
	    Error in bgerror: can't invoke "grab" command:  application has been destroyed
	bgerror failed to handle background error.
	    Original error: invalid command name ".ptop.comm.t"
	    Error in bgerror: can't invoke "tk" command:  application has been destroyed

    Maybe it should be ignored.

 3. Finally, I find the difference between clicking on a file name
    versus clicking on a file icon a bit strange. I continue on the
    example above, first modifying gitool and then creating a new file,
    so a file is listed both under "Modified files" and "Untracked/new
    files".

	1. Click on the file name of the modified file to see the diff
	   in the content buffer.

	2. Click on the file icon of the untracked file to add it. State
	   shows "Added" and the content buffer is cleared.

    I have to press the file name to see the content of the added file.
    Maybe it should show the content regardless of whether the file name
    or icon was pressed.

Jonas Fonseca writes:

Hmmm, I didn't think that could happen. :) It can only happen if some file gets listed twice in the output from "git-diff-index HEAD". Could you send me the output of "git-diff-index HEAD" and "git-diff-index --cached HEAD" in that repository?

And no, you don't need to run git-update-index, gitool does that for you.

Paul.

Paul Mackerras <paulus@samba.org> wrote Tue, Sep 05, 2006:

~/gitool > git-diff-index HEAD fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions ~/gitool > git-diff-index --cached HEAD fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions ~/gitool > cat .git/HEAD ref: refs/heads/master ~/gitool > ls .git/refs/heads/ ~/gitool >

Good to hear, but I swear the first time I ran gitool in a repo of mine it popped up the error dialog with the details saying:

	fileX: needs update

Now, of course, I cannot reproduce it.