Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 06/10/2011 11:48 PM, Junio C Hamano wrote: >> In short, the proposed "NEXT" does not help in a situation with conflicts, >> and makes the user experience worse. > > The idea of "NEXT" and its friends would indeed be marginal if it only > applied to "git diff". The real gain in learnability comes from using > the same idioms in other commands where they make sense; for example, > > # More consistent alternative to the special "--ours" option: > git checkout OURS -- Makefile I do not see much improvement over --ours here. > # This would add more completeness to the > # "git checkout <tree-ish> -- PATH" command, and would remain the > # default if no <tree-ish> is specified: > git checkout NEXT -- Makefile > git show NEXT:Makefile Now, during conflict, you admitted that NEXT would not be helpful for "diff", but these are even more dubious during conflict. The point of index that can keep conflicted state (in fact, contrary to some misperception, index is where the real merge happens, and updating the working tree is merely to _help_ users to help the index resolve the conflicts, not the other way around) is that until you resolve conflicts, "the state for the NEXT commit" is not defined. How would it improve the support we give to users when you give NEXT to them, compared with the current system, if you have to say "NEXT" works most of the time to represent what you would commit next? You have to also tell them that in some circumstances there cannot be "NEXT" until they resolve conflicts, and then they need to learn how to do so with the index. They need to learn the real thing at that point, unlearning fuzzily defined "NEXT" illusion. I certainly do not have any objection against making system easier to understand, and I do not think implementation complexity nor performance should trump the usability (I also do not think various conflicting semantics of proposed "NEXT" are hard to implement efficiently). I however doubt "NEXT" would help to give users any better understanding, and that is the biggest problem I have with this topic. -- 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