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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html