Re: [1.8.0] use 'stage' term consistently
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- May 20, 2012, 18:06 UTC
- Message-ID
- <20120520180606.GC3000@burratino>
- In-Reply-To
- <CAMP44s2bbJLgqOdi49jS34E79EvNtRifpCbDE_bQUys+3xrs3w@mail.gmail.com>
Felipe Contreras wrote:
> On Sat, May 19, 2012 at 8:32 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 9 quoted lines
>> 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