Re: [RFC/PATCH 0/2] New 'stage' command

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Apr 5, 2009, 23:06 UTC
Message-ID: <20090405230655.GB20356@atjola.homenet>
In-Reply-To: <94a0d4530904051535v8bd901fsedecdf61bc4acb33@mail.gmail.com>

On 2009.04.06 01:35:24 +0300, Felipe Contreras wrote:

Show 17 quoted lines

> On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > Felipe Contreras, 05.04.2009:
> >> For example 'git stage diff' is more natural (at least to me) than 'git diff
> >> --cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.
> >
> > Not for me. If I want to GET a diff, I want to use a command "diff", so
> > "git diff" is more obvious.
> > The next step is to say WHAT exactly to diff. Therefor options to the
> > "diff" command are more logically to me from a hierarchic POV. And here
> > I don't think options like "--cached" or "sha1..sha2", despite having
> > different style, make any difference.
> 
> Well, it's a matter of preference, and you would not loose the option
> to do it the way you like. But actually, "git diff --cached" is a
> different action; you can't do "git diff --cached HEAD^.." for
> example.

Sure you can. It diffs the index against HEAD^

> Consider "git rm foo.c" vs "git rm --cached foo.c"... both commands
> are removing a file, the only difference is that one is removing from
> the staging area while the other is removing it from the working
> directory.

The working tree _and_ the index. To delete it only from the working tree you need "rm", not "git rm".

Show 5 quoted lines

> Now think about "git branch -d bar", following the "first I
> specify the action, and then the object" thinking, would it make sense
> to have "git rm --branch bar"? Probably not; if you want to do stuff
> with branches, you use "git branch", similarly, if you want to do
> stuff with the staging area, why not use "git stage"?

If you're going that way, you'll also need "clone create", "working-tree grep", "repo/remote fetch/pull/push", etc.

"git branch", "git tag", "git remote" and maybe "git status" are the "outsiders", in that the commands (in some forms) end up as "git <object> <action>" form. The rest is "git <action> <object>".

So "git stage <action>" would extend the minority, and not lead to unification.

Björn