On Tue, 7 June 2011, Michael J Gruber wrote: > Junio C Hamano venit, vidit, dixit 06.06.2011 18:14: > > 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. I think one can see __ad hominem__ attack in *implication* that the idea got shot down because of Junio (and Linus) _personal_ resistance to fresh ideas. And that is Junio stubborness than stand in the way of new ideas. Certainly somebody more sensitive might read it as such. > 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. Those "attacks" are at ideas and arguments, not at people. > 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). Well, some of current overloading might be leftover result of "git is too complicated, see how many commands it have [in $PATH]" criticism of git and comparison with other (D)VCS... and in reducing number of commands the pendulum perhaps went too far in opposite direction. I don't quite think that we need "git diff NEXT WTREE"; the short and sweet "git diff" is short for a reason, see my other response in this thread: http://thread.gmane.org/gmane.comp.version-control.git/175061/focus=175265 and that the pseudo-almost-ref notation it would require for each such pseudo-ref considering many corner cases: git diff <pseudo-ref-A> <pseudo-ref-B> git diff <commit or tree> <pseudo-ref> git diff <pseudo-ref> git show <pseudo-ref> in normal and in conflicted case. I am also not sure if replacing "context-sensitive" git-checkout behavior by "git revert-file" (or rather "git revert-path", as you can use pathspec, c.f. "git checkout ."), is something to consider without rock-solid UI design and a very good name. True, context dependent grammars are harder than context-free grammars, but people do understand context, don't they? Anyway, if one does not remember "git checkout -- <file>", one can always use obvious alternative, namely "git show :./<file> > <file>"... BUT I quite like "git unadd" (and/or "git unstage") idea. It is not obvious that "git reset" can be used for files, and it requires bit of analysis that it resets index from HEAD: 1. "git reset [<options>]" always resets from commit (defaults to HEAD), 2. "git reset" == "git reset --mixed" modifies current branch and index (HEAD -> index -> worktree progression of --soft -> --mixed -> --hard et al.), 3. modifying branch tip doesn't make sense for checking out file, so 4. "git reset -- <file>" must set index version of file from HEAD. Truth to be told I really just follow what "git status" tells me ;-) Though I am always wondering why there isn't "git reset --hard <file>" to mean the same as "git checkout HEAD <file>". So +1 from me for "git unadd [<commit>] [--] <path>..." (and "git unstage") to do _exactly the same_ as "git reset [<commit>] [--] <path>...". -- Jakub Narebski Poland -- 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