Junio C Hamano venit, vidit, dixit 06.06.2011 18:14: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >>> That is why I asked what the user experience of "git show NEXT" as opposed >>> to "git show INDEX" should look like. So what should it look like during a >>> "pull" that did not finish? >> >> If NEXT is to mean the result of a commit in the current state, and the >> current state would or should not allow a commit, then trying to access >> that pseudo-commit should error out with a helpful message. > > What "helpful message"? I asked for the user experience, not handwaving. I specified the exit behaviour, that is no handwaving. [...] >> Another option is to make NEXT/INDEX mean a tree (:0:). I have not >> thought this through (and have not made a suggestion, accordingly) but I >> do see a problem in the UI. (I don't think we need to change the >> existing ui in that respect but can amend and improve it.) >> >> Anyway, it's rc phase :) > > Rc or not rc, I spend my limited git time running builds and tests for master on several systems these days (and following changed build environments there which I can't control). > just repeating a fuzzy and uncooked "idea" around phoney > ref-looking names that will end up confusing the users, and selling that > as if it is a logical conclusion to "we want to give an easier to > understand UI", without presenting a solid user experience design that is > convincing enough that the "idea" will reduce confusion will not get us > anywhere, especially when it is sprinkled with ad hominem attack at me. I've re-read all my posts in this thread and have no idea what you're referring to here. If I were more sensitive I could spot attacks at myself in the above, though. Just count your usage of terms like "phoney", "fuzzy" etc. directed at other people's ideas and arguments. I'm actually wondering whether there is any agreement on the sheer fact that there is a problem in the ui, namely having too many different commands or options (reset/commit/add/checkout resp. diff invocations; I've described that already) for different aspects of a "similar" concept (cp content version from A to B resp. diff it). If we don't agree that there's a problem then there's no point discussing solutions (or ideas/brainstorms thereof). Michael -- 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