New git commit tool

New git commit tool

[Paul Mackerras]

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.

-- 
VGER BF report: U 0.977306

Re: New git commit tool

[Jakub Narebski]

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...

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git



-- 
VGER BF report: U 0.98878

Re: New git commit tool

[Linus Torvalds]

On Mon, 4 Sep 2006, Paul Mackerras wrote:
> 
> 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. :)

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

Re: New git commit tool

[Paul Mackerras]

Linus Torvalds writes:

> 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 ;)

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.

Re: New git commit tool

[Linus Torvalds]

On Tue, 5 Sep 2006, Paul Mackerras wrote:
> 
> 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...

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

Re: New git commit tool

[Karl Hasselström]

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

> 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...

gitci?

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: New git commit tool

[Jonas Fonseca]

Paul Mackerras <paulus@samba.org> wrote Mon, Sep 04, 2006:
> Comments and suggestions are welcome.

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

Re: New git commit tool

[Paul Mackerras]

Jonas Fonseca writes:

>     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

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.

Re: New git commit tool

[Jonas Fonseca]

Paul Mackerras <paulus@samba.org> wrote Tue, Sep 05, 2006:
> Jonas Fonseca writes:
> 
> >     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
> 
> 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?

~/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 >

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

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.

-- 
Jonas Fonseca