Re: Officially start moving to the term 'staging area'

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

 



Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:

> It has been discussed many times in the past that 'index' is not an
> appropriate description for what the high-level user does with it, and
> it has been agreed that 'staging area' is the best term.

Thanks for working on this. No time for a really detailed review, but a
few remarks.

> The term 'staging area' is more intuitive [...]
>
> The first step in moving Git towards this term, is first to add --stage
> options for every command that uses --index or --cache.

These explanations make sense. I think it would be better to put part of
it in commit messages, so that future contributors can "git blame" the
doc/implem of these --stage and find them (i.e. avoid the
misunderstanding that occured with "git stage" command which was
proposed for removal).

> After adding the new --stage options and making sure no functionality is
> lost, they can become the recommended ones in the documentation,
> eventually, the old ones get deprecated, and eventually obsoleted.

Same: putting this in the commit message would cast in stone that we
want to obsolete the old ones.

(But that was nice to have this cover-letter)

> Moreover, the --stage and --work

--work alone sounds weird. At least to me, it does not immediately imply
"working tree". It is tempting to call the option --work-tree, but git
already has a global option with that name (git --work-tree=foo bar).

Perhaps --worktree to limit the confusion?

> reset', and after these options are added, the complicated table to
> explain the different behaviors between --soft, --mixed, and --hard
> becomes so simple it's not needed any more:

I didn't understand the table, but yes, the --soft, --mixed, and --hard
is terrible, I need to read the doc whenever I do something non-trivial
with reset :-(.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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]