Consistent terminology: cached/staged/index

classic Classic list List threaded Threaded
65 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Consistent terminology: cached/staged/index

Piotr Krukowiecki
Hi,

is there a plan for using one term instead of three to describe
operations on index?

From quick search:
* "add" mentions index and staging
* all commands except one take "--cached" only
* "diff" also takes "--staged"
* "diff" mentions index and staging
* "log" mentions index
* "reset" mentions index


--
Piotrek
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Jonathan Nieder-2
Piotr Krukowiecki wrote:

> is there a plan for using one term instead of three to describe
> operations on index?

No.  But ideas (and especially patches) for improving the
documentation would be appreciated.

> From quick search:
> * "add" mentions index and staging
> * all commands except one take "--cached" only
> * "diff" also takes "--staged"
> * "diff" mentions index and staging
> * "log" mentions index
> * "reset" mentions index

If I understand correctly, the intended semantics are:

--index versus --cached
~~~~~~~~~~~~~~~~~~~~~~~
The place where changes for the next commit get registered is called
the "index file".

Commands that pay attention to the registered content of files rather
than the copies in the work tree use the option name "--cached".  This
is mostly for historical reasons --- early on, it was not obvious that
making the index not match the worktree was going to be useful.

Commands that update the registered content of files in addition to
the worktree use the option name "--index".

--staged
~~~~~~~~
diff takes --staged, but that is only to support some people's habits.

The term "to stage" is generally an abbreviation for "to stage in the
index", meaning "to mark for use in the next commit".  It is used to
paint a certain picture of the process in which one makes sure
everything is just right before committing to the result.

Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Junio C Hamano
Jonathan Nieder <[hidden email]> writes:

> If I understand correctly, the intended semantics are:
>
> --index versus --cached
> ~~~~~~~~~~~~~~~~~~~~~~~
> The place where changes for the next commit get registered is called
> the "index file".
>
> Commands that pay attention to the registered content of files rather
> than the copies in the work tree use the option name "--cached".  This
> is mostly for historical reasons --- early on, it was not obvious that
> making the index not match the worktree was going to be useful.
>
> Commands that update the registered content of files in addition to
> the worktree use the option name "--index".

Mostly correct, except the "early on, it was not obvious" part.  It was
very obvious from the early days that unlike "cvs commit" or "svn commit"
it was very useful that you can trust "git commit", after preparing the
index with what is and isn't to be included in the commit, won't pick up
debugging cruft you keep around in the working tree.

"cache" was an old name (and still established name in-use in the code)
for the index.  Some commands make sense to affect both the index and the
working tree (e.g. "apply") and you give --index to mean "both index and
the working tree" while some other operating modes that make sense only to
look at the index, ignoring the potential difference between the working
tree and the index (e.g. again "apply"), iow, taking only the cached
changes into account, are invoked with --cached to mean "look only at what
is recorded in the index".

Some people may find it a good idea to introduce new synonyms --index-only
vs --index-and-working-tree. I personally am not opposed to such a change,
as long as traditional --cached vs --index will keep working for people
who already learned the difference.  These hypothetical new synonyms would
be more descriptive; the necessity to differenciate the two concepts the
two options --cached vs --index try to tell apart is very real, but it was
a hack to use these two particular words --cached vs --index to do so
without trying harder to come up with better words.


> --staged
> ~~~~~~~~
> diff takes --staged, but that is only to support some people's habits.

This one actually needs more historical background to understand why it is
there, as the synonym is not necessary to understand how git works.

Originally, the way to say "what is in the current working tree for this
path is what I want to have in the next commit" was "update-index".  "What
I want to have in the next commit" is "the index", and the operation is
about "updating" that "What I want to have...", so the name of the command
made perfect sense.  "update-index" had a safety valve to prevent careless
invocation of "update-index *" to add all the cruft in the working tree
(there wasn't any .gitignore mechanism in the Porcelain nor in the
plumbing) and by default affected only the paths that are already in the
index.  You needed to say "update-index --add" to include paths that are
not in the index.

A more user friendly Porcelain "git add" was later implemented in terms of
"update-index --add", but originally it was to add new paths; updating the
contents was still done via "update-index" interface.

This changed in v1.5.0, around the beginning of 2007.  Nicolas Pitre among
others realized that git is about tracking contents, not paths, which
meant that "make the content in the working tree at this moment appear in
the next commit" is equivalent to saying "add this _content_ to the set of
contents that make up the next commit".  "git add" learned to accept both
new paths that were not in the index so far and also paths known to the
index that had old contents for them.

Before v1.5.0, we explained the concept as "we update the set of contents
to be in the next commit" (hence "update-index"); since v1.5.0, we explain
the concept as "we add what's in these paths to the set of contents to be
in the next commit" (hence "add").

Notice that there is no need for a new terminology "staged" in the above
description?

The semantics of the index didn't change ever since, modulo small tweaks
like "add -i" (I borrowed it from Darcs) that allows us to say "add parts
of the changed content" instead of the "what's in the file as a whole
right now" were added; these small tweaks didn't introduce any conceptual
change.

The term "stage" comes from "staging area", a term people used to explain
the concept of the index by saying "The index holds set of contents to be
made into the next commit; it is _like_ the staging area".

My feeling is that "to stage" is primarily used, outside "git" circle, as
a logistics term.  If you find it easier to visualize the concept of the
index with "staging area" ("an area where troops and equipment in transit
are assembled before a military operation", you may find it easier to say
"stage this path ('git add path')", instead of "adding to the set of
contents...".

Although I tried to use the word myself in earlier days, I have never felt
that "staging area" is a very widely known term for non-native speakers of
English, and personally have tended to avoid using it.  I find "adding to
the set of contents..." somewhat easier to understand regardless of your
language background, but it may be just me who is not a native speaker.

In short, "stage" is an unessential synonym that came much later, and that
is why we avoid advertising it even in the document of "git diff" too
heavily.  Unlike the hypothetical --index-only synonym for --cached I
mentioned earlier that adds real value by being more descriptive, "staged"
does not add much value over what it tried to replace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Miles Bader-2
Junio C Hamano <[hidden email]> writes:
> Some people may find it a good idea to introduce new synonyms --index-only
> vs --index-and-working-tree. I personally am not opposed to such a change,

Those are so long that nobody will ever use them though...

One of my big peeves is simply that "git diff --cached" is too long, as
it's an extremely common command (the name isn't exactly intuitive, even
after many years of use, but it's just one of those things you
memorize).

Is there a reason a short version of --cached couldn't be added to
git-diff...?  E.g. "git diff -c"?

Thanks,

-Miles

--
Ocean, n. A body of water covering seven-tenths of a world designed for Man -
who has no gills.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Pete Harlan
In reply to this post by Junio C Hamano
On 02/13/2011 02:58 PM, Junio C Hamano wrote:

>> --staged
>> ~~~~~~~~
>> diff takes --staged, but that is only to support some people's habits.
> The term "stage" comes from "staging area", a term people used to explain
> the concept of the index by saying "The index holds set of contents to be
> made into the next commit; it is _like_ the staging area".
>
> My feeling is that "to stage" is primarily used, outside "git" circle, as
> a logistics term.  If you find it easier to visualize the concept of the
> index with "staging area" ("an area where troops and equipment in transit
> are assembled before a military operation", you may find it easier to say
> "stage this path ('git add path')", instead of "adding to the set of
> contents...".

FWIW, when teaching Git I have found that users immediately understand
"staging area", while "index" and "cache" confuse them.

"Index" means to them a numerical index into a data structure.
"Cache" is a local copy of something that exists remotely.  Neither
word describes the concept correctly from a user's perspective.

I learned long ago to type "index" and "cached", but when talking (and
thinking) about Git I find "the staging area" gets the point across
very clearly and moves Git from interesting techie-tool to
world-dominating SCM territory.  I'm surprised that that experience
isn't universal.

--Pete
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Junio C Hamano
In reply to this post by Miles Bader-2
Miles Bader <[hidden email]> writes:

> Is there a reason a short version of --cached couldn't be added to
> git-diff...?  E.g. "git diff -c"?

I'd suspect that we would like to keep the door open for "diff -c" to do
what the users naturally expect, namely, to produce a patch in the copied
context format.

I don't immediately plan to do so myself, though.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Miles Bader-2
On Mon, Feb 14, 2011 at 5:57 AM, Junio C Hamano <[hidden email]> wrote:
>> Is there a reason a short version of --cached couldn't be added to
>> git-diff...?  E.g. "git diff -c"?
>
> I'd suspect that we would like to keep the door open for "diff -c" to do
> what the users naturally expect, namely, to produce a patch in the copied
> context format.

hmm

"git diff -s"  ? ... since --staged is an alias for --cached :)

-miles

--
Cat is power.  Cat is peace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Johannes Sixt-2
Am 2/14/2011 7:27, schrieb Miles Bader:
> "git diff -s"  ? ... since --staged is an alias for --cached :)

git config --global alias.diffc "diff --cached"

?

-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Miles Bader-2
On Mon, Feb 14, 2011 at 6:59 AM, Johannes Sixt <[hidden email]> wrote:
> Am 2/14/2011 7:27, schrieb Miles Bader:
>> "git diff -s"  ? ... since --staged is an alias for --cached :)
>
> git config --global alias.diffc "diff --cached"

"Git should be convenient by default (for commonly used operations)"

-miles

--
Cat is power.  Cat is peace.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

MichaelJGruber
Miles Bader venit, vidit, dixit 14.02.2011 08:07:

> On Mon, Feb 14, 2011 at 6:59 AM, Johannes Sixt <[hidden email]> wrote:
>> Am 2/14/2011 7:27, schrieb Miles Bader:
>>> "git diff -s"  ? ... since --staged is an alias for --cached :)
>>
>> git config --global alias.diffc "diff --cached"
>
> "Git should be convenient by default (for commonly used operations)"
>
> -miles
>

git diff --ca<TAB>

;)

At least if "by default" includes using the default bash completion by
default.

Short options should really not be "wasted" easily. "-s" named after "to
stage" is really problematic, as outlined in this thread. It's mainly
used (and has been introduced, I think) by "the other git community", so
to say. I feel that sticking to established terminology (esp. that used
in man pages and command messages) is more helpful for newbies. That
does not exclude using new terms for explaining that terminology, of course.

The term "stage" is in git's documentation all over the place - and
denotes the different versions of a blob involved in a merge.
Admittedly, that's something recorded in the index.

Full disclaimer: I have an alias "staged" for "diff --cached" myself...

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Miles Bader-2
Michael J Gruber <[hidden email]> writes:
> Short options should really not be "wasted" easily. "-s" named after "to
> stage" is really problematic, as outlined in this thread.

Er, but the point is that this is _such_ a common operation, that a
short option for it would not be "wasted" at all.  [The whole concept of
"wasting" short options doesn't even make sense unless you're willing to
then use the resulting "preserved" options eventually...]

Indeed it seems a little weird that there's not one for this already,
given how common short options are in git generally, often for far less
useful options than --cached/--staged; I can only guess that the reason
is basically historical accident.

As for the exact letter chosen, "-s" seems perfectly fine to me.  Short
options do not need to be "perfect" to be useful, and the connection
with --staged is a perfectly plausible memory aid for that short period
during which people memorize them.

-Miles

--
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Duy Nguyen
In reply to this post by MichaelJGruber
On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
<[hidden email]> wrote:
> Full disclaimer: I have an alias "staged" for "diff --cached" myself...

Be careful with your fingers. There's a command named "git stage".
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

MichaelJGruber
Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
> <[hidden email]> wrote:
>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>
> Be careful with your fingers. There's a command named "git stage".

I know. Can we remove it as part of 1.8.0? It's our only builtin alias.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Duy Nguyen
On Mon, Feb 14, 2011 at 8:43 PM, Michael J Gruber
<[hidden email]> wrote:
> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
>> <[hidden email]> wrote:
>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>>
>> Be careful with your fingers. There's a command named "git stage".
>
> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.

It's out in the field. I don't think we can just simply remove it.
It'd be nice though to have a mechanism to override (or even remove,
in your case) builtin commands, or at least porcelain ones. A feature
with a big "your feet is expected to be shot by yourself" warning.
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Felipe Contreras
In reply to this post by MichaelJGruber
On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber
<[hidden email]> wrote:
> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
>> <[hidden email]> wrote:
>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>>
>> Be careful with your fingers. There's a command named "git stage".
>
> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.

I have proposed before to extend 'git stage', so you can do 'git stage
diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This
would not conflict with the old behavior of 'git stage $file'.

case "$1" in
add)
        shift
        git add $@
        ;;
rm)
        shift
        git rm --cached $@
        ;;
diff)
        shift
        git diff --cached $@
        ;;
import)
        shift
        git ls-files --modified --others --exclude-standard -z $@ | \
        git update-index --add --remove -z --stdin
        ;;
ls)
        shift
        git ls-files --stage $@
        ;;
*)
        git add $@
        ;;
esac

Cheers.

--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Duy Nguyen
On Mon, Feb 14, 2011 at 9:17 PM, Felipe Contreras
<[hidden email]> wrote:

> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber
> <[hidden email]> wrote:
>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
>>> <[hidden email]> wrote:
>>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>>>
>>> Be careful with your fingers. There's a command named "git stage".
>>
>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.
>
> I have proposed before to extend 'git stage', so you can do 'git stage
> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This
> would not conflict with the old behavior of 'git stage $file'.

It does. What if I want to stage a file named "add", "rm" or "diff"?
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Jakub Narębski
Nguyen Thai Ngoc Duy <[hidden email]> writes:
> On Mon, Feb 14, 2011 at 9:17 PM, Felipe Contreras
> <[hidden email]> wrote:
>> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber
>> <[hidden email]> wrote:
>>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
>>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
>>>> <[hidden email]> wrote:

>>>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>>>>
>>>> Be careful with your fingers. There's a command named "git stage".
>>>
>>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.
>>
>> I have proposed before to extend 'git stage', so you can do 'git stage
>> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This
>> would not conflict with the old behavior of 'git stage $file'.
>
> It does. What if I want to stage a file named "add", "rm" or "diff"?

Then you would use

  $ git stage ./diff

or

  $ git stage -- diff

(or even "git add diff" ;-)).

P.S. I haven't checked that above work...

--
Jakub Narebski
Poland
ShadeHawk on #git
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

MichaelJGruber
In reply to this post by Felipe Contreras
Felipe Contreras venit, vidit, dixit 14.02.2011 15:17:

> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber
> <[hidden email]> wrote:
>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
>>> <[hidden email]> wrote:
>>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>>>
>>> Be careful with your fingers. There's a command named "git stage".
>>
>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.
>
> I have proposed before to extend 'git stage', so you can do 'git stage
> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This
> would not conflict with the old behavior of 'git stage $file'.
>
> case "$1" in
> add)
>         shift
>         git add $@
>         ;;
> rm)
>         shift
>         git rm --cached $@
>         ;;
> diff)
>         shift
>         git diff --cached $@
>         ;;
> import)
>         shift
>         git ls-files --modified --others --exclude-standard -z $@ | \
>         git update-index --add --remove -z --stdin
>         ;;
> ls)
>         shift
>         git ls-files --stage $@
>         ;;
> *)
>         git add $@
>         ;;
> esac
>
> Cheers.
>

In principle I like this a lot: a set of commands operating on/with the
stage/index/cache consistently. It think it's similar in (good) spirit
to our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to
give that somewhat nebulous (for noobs) index a more concrete
"appearance", not hidden away in options (--index, --cached) and
defaults (diff against index by default).

In our case, however, I think the design principle deviates from our
common form:

git foo bar

usually means "do foo" to "bar", as most of our common commands are
verbs (being applied to the object "bar"). When it comes to subcommands
we do have inconsistencies already (double-dashed vs. undashed, e.g.),
but I'd prefer fewer ;)

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

Felipe Contreras
On Mon, Feb 14, 2011 at 5:24 PM, Michael J Gruber
<[hidden email]> wrote:

> Felipe Contreras venit, vidit, dixit 14.02.2011 15:17:
>> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber
>> <[hidden email]> wrote:
>>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
>>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
>>>> <[hidden email]> wrote:
>>>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>>>>
>>>> Be careful with your fingers. There's a command named "git stage".
>>>
>>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.
>>
>> I have proposed before to extend 'git stage', so you can do 'git stage
>> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This
>> would not conflict with the old behavior of 'git stage $file'.

[...]

> In principle I like this a lot: a set of commands operating on/with the
> stage/index/cache consistently. It think it's similar in (good) spirit
> to our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to
> give that somewhat nebulous (for noobs) index a more concrete
> "appearance", not hidden away in options (--index, --cached) and
> defaults (diff against index by default).
>
> In our case, however, I think the design principle deviates from our
> common form:
>
> git foo bar
>
> usually means "do foo" to "bar", as most of our common commands are
> verbs (being applied to the object "bar"). When it comes to subcommands
> we do have inconsistencies already (double-dashed vs. undashed, e.g.),
> but I'd prefer fewer ;)

Except 'git branch', 'git tag', 'git remote', 'git stash', and 'git
submodule'. In fact, every logical object in git seems to have their
own command, except the stage.

--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: Consistent terminology: cached/staged/index

MichaelJGruber
Felipe Contreras venit, vidit, dixit 14.02.2011 17:00:

> On Mon, Feb 14, 2011 at 5:24 PM, Michael J Gruber
> <[hidden email]> wrote:
>> Felipe Contreras venit, vidit, dixit 14.02.2011 15:17:
>>> On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber
>>> <[hidden email]> wrote:
>>>> Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:
>>>>> On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
>>>>> <[hidden email]> wrote:
>>>>>> Full disclaimer: I have an alias "staged" for "diff --cached" myself...
>>>>>
>>>>> Be careful with your fingers. There's a command named "git stage".
>>>>
>>>> I know. Can we remove it as part of 1.8.0? It's our only builtin alias.
>>>
>>> I have proposed before to extend 'git stage', so you can do 'git stage
>>> diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This
>>> would not conflict with the old behavior of 'git stage $file'.
>
> [...]
>
>> In principle I like this a lot: a set of commands operating on/with the
>> stage/index/cache consistently. It think it's similar in (good) spirit
>> to our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to
>> give that somewhat nebulous (for noobs) index a more concrete
>> "appearance", not hidden away in options (--index, --cached) and
>> defaults (diff against index by default).
>>
>> In our case, however, I think the design principle deviates from our
>> common form:
>>
>> git foo bar
>>
>> usually means "do foo" to "bar", as most of our common commands are
>> verbs (being applied to the object "bar"). When it comes to subcommands
>> we do have inconsistencies already (double-dashed vs. undashed, e.g.),
>> but I'd prefer fewer ;)
>
> Except 'git branch', 'git tag', 'git remote', 'git stash', and 'git
> submodule'. In fact, every logical object in git seems to have their
> own command, except the stage.
>

Yes, remote, stash and submodule are the ones with the different
subcommand handling I mentioned: the subcommand is the verb, and
specified undashed.

We have other commands with double-dashed (i.e. option) subcommands,
such as "brach --set-upstream", and others single-dashed, such as "tag -v".

Note that branch, tag and stash are verbs as well as nouns.

I just think that "git verb object" is the more prevalent order, so that
we should move in that direction if we want make things better. Other
than that I would have no objection against "git object verb".

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
1234