git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: New git commit tool

From
Linus Torvalds <torvalds@osdl.org>
Date
Sep 4, 2006, 17:10 UTC
Message-ID
<Pine.LNX.4.64.0609040952550.27779@g5.osdl.org>
In-Reply-To
<17660.4995.977221.767112@cargo.ozlabs.ibm.com>
On Mon, 4 Sep 2006, Paul Mackerras wrote:
Show 5 quoted lines
> 
> 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
Previous: Jakub NarebskiNext: Paul Mackerras
Message 3 of 9 in “New git commit tool”
  1. Paul MackerrasSep 4, 2006
  2. Jakub NarebskiSep 4, 2006
  3. Linus TorvaldsSep 4, 2006
  4. Paul MackerrasSep 4, 2006
  5. Linus TorvaldsSep 4, 2006
  6. Karl HasselströmSep 5, 2006
  7. Jonas FonsecaSep 4, 2006
  8. Paul MackerrasSep 4, 2006
  9. Jonas FonsecaSep 5, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.