Re: [1.8.0] use 'stage' term consistently

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: May 20, 2012, 12:04 UTC
Message-ID: <CAMP44s2bbJLgqOdi49jS34E79EvNtRifpCbDE_bQUys+3xrs3w@mail.gmail.com>
In-Reply-To: <20120519063208.GA24556@burratino>

On Sat, May 19, 2012 at 8:32 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 19 quoted lines

> 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.

Show 16 quoted lines

> 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