Re: [1.8.0] use 'stage' term consistently

[Jonathan Nieder <jrnieder@gmail.com>]

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

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

They are commands because they are passed on the command line.  I don't
care strongly about the details --- I was giving an idea for people to
pick up or not pick up.

[...]
>> Maybe:
>>
>>        git apply --index=(yes | no | only)
[...]
> '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

It is 'index' because the command already has an option with that
name, which makes this more discoverable and less confusing to
existing users.  You can like or not like that choice.

How do you negate the "also stage this change for the next commit"
option passed earlier on the command line?

I also don't care about the details here and wish you had phrased your
critique in terms of an alternate proposal instead of asking me to
defend mine.  The only part I actually care about is that a person
should think carefully about individual changes, in isolation, that
improve git and move towards a more pleasant and consistent interface.

I don't see any reason for a flag day.

Hope that helps,
Jonathan