From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Sun, 20 May 2012 12:04:46 GMT
Subject: Re: [1.8.0] use 'stage' term consistently
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:
> 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