On Mon, Feb 14, 2011 at 5:24 PM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Felipe Contreras venit, vidit, dixit 14.02.2011 15:17: >> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber >> <git@xxxxxxxxxxxxxxxxxxxx> wrote: >>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14: >>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber >>>> <git@xxxxxxxxxxxxxxxxxxxx> wrote: >>>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself... >>>> >>>> Be careful with your fingers. There's a command named "git stage". >>> >>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias. >> >> I have proposed before to extend 'git stage', so you can do 'git stage >> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This >> would not conflict with the old behavior of 'git stage $file'. [...] > In principle I like this a lot: a set of commands operating on/with the > stage/index/cache consistently. It think it's similar in (good) spirit > to our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to > give that somewhat nebulous (for noobs) index a more concrete > "appearance", not hidden away in options (--index, --cached) and > defaults (diff against index by default). > > In our case, however, I think the design principle deviates from our > common form: > > git foo bar > > usually means "do foo" to "bar", as most of our common commands are > verbs (being applied to the object "bar"). When it comes to subcommands > we do have inconsistencies already (double-dashed vs. undashed, e.g.), > but I'd prefer fewer ;) Except 'git branch', 'git tag', 'git remote', 'git stash', and 'git submodule'. In fact, every logical object in git seems to have their own command, except the stage. -- Felipe Contreras -- 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