On Sat, May 19, 2012 at 8:32 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Jonathan Nieder wrote: > >> For the sake of having a proposal: :) > > For the command-line interface: > > Making the "git stage" command more prominent. Unfortunately it is > currently a synonym for "git add", which makes "git rm" less > discoverable and generally isn't very helpful. But if we discard that > property, it could become a nice way to make some operations more > discoverable: > > git stage --add <paths>; # stage an addition > git stage --remove <paths>; # stage a removal > git stage --edit <paths>; # edit the staged content > git stage --apply <patch>; # stage the described change > > These would be commands that modify the index without touching the > worktree. If they are commands, why do they start with --? 'git stage add' 'git stage remove' 'git stage edit' Would be more appropriate. But I think revamping 'git stage' should be a separate task. > Finding a better mnemonic than "also update the current directory cache" > and "trust the current directory cache" for operations like git apply > --index and git grep --cached. Better concepts would be "search the > content staged for the next commit" and "also update the staged > content". > > Maybe: > > git apply --index=(yes | no | only) > # apply = apply --index=no > # apply --index = apply --index=yes > # apply --cached = apply --index=only > > git grep --index; # (= git grep --cached) > > I imagine others can come up with something better. 'index'? That goes contrary to this request; the term 'index' should be avoided in porcelain commands. s/index/stage/ and the proposal seems sensible, but I fail to see how --stage=no could be helpful, and --stage=yes should be the same as --stage, and then I wonder what would be the purpose of having --stage, and --stage=only, where we could have a --stage(d)-only for commands that need this distinction (not all of them). If in the future we want more --stage=foo options, then it might make sense, but I just don't see that ever happening. I guess the next step would be to list all the commands that use --index, --staged, and --cached, and propose new options that would eventually help to remove --index and --cached (after some period of deprecation). Cheers. -- 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