On 07.06.2011 13:45, Jonathan Nieder wrote: [...]
If there were an unmerged path in the index, this would do a three-way diff, just like "git diff" currently does. That all sounds great, but I do not find it completely satisfactory. One problem is that if this is the mental model people have of "git diff", the three-way diff for a multiple stages, behavior of "git diff<paths>", and so on, however they are spelled, will look completely mystifying. From the point of view of "this command explains the changes in the worktree" they make sense, while from the point of view of "compare A to B" they don't make much sense at all. So this change just defers the learning process.
If someone finds the three-way diff completely mystifiying, how do you expect him to resolve a merge conflict at all? Or recognize that there is one? Or find the command to use after editing out the conflict markers?
A novice user will have no real mental model anyway. He will be looking for simple (and easy to remember) commands for (mostly) simple needs.
I think part of the problem in the current UI is that the documentation never spells out the idea of what plain "git diff" is for. Worse, "--cached means to look to the index in place of the worktree" doesn't seem to be spelled out anywhere except gitcli(7). I am not sure it is worth the headache of spelling the latter out instead of changing the UI to be easier to explain. Something like "git diff --index-only" would at least set people thinking in the right direction --- "index only as opposed to what?". With an INDEX pseudo-tree, git diff INDEX is a synonym for "git diff", and to do "git diff --cached" one would have to write git diff HEAD INDEX I like the "rename --cached to --index-only" proposal more but am not too satisfied with it, either. In a way it is tempting to teach people git diff-files -p; # compare worktree to index git diff-index -p HEAD; # compare worktree to HEAD git diff-index -p --cached HEAD; # compare index to HEAD git diff-tree -p HEAD HEAD^; # compare HEAD^ to HEAD
if you look at the comments you put behind the commands, they look very much like the proposed diff command. How much time would a novice (and everyone else) need to remember your comments compared to your commands? A lot less.
Holger. -- 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