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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Felipe Contreras, 06.04.2009:
> On Mon, Apr 6, 2009 at 12:58 AM, Markus Heidelberg
> <markus.heidelberg@xxxxxx> 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.

I know, but that's not the topic.

> But actually, "git diff --cached" is a
> different action; you can't do "git diff --cached HEAD^.." for
> example.

And I neither could I do "git stage diff 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. 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;

Right, the argumentation with first the action doesn't fly any more.
I guess it has to be considered what makes sense to have as command.
"rm" (not git-rm) is such a well-known tool for deleting files so it
probably doesn't make sense to have a command git-rm-files instead.

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

So git-diff for working with diffs, git-branch for working with
branches and git-rm/git-add for working on file level makes sense for
me. Whether the a command can work with both the working tree and the
index doesn't seem to make a difference for me.

Markus

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]