Re: What is missing from Git v2.0

From: Theodore Ts'o <tytso@mit.edu>
Date: Apr 25, 2014, 13:35 UTC
Message-ID: <20140425133520.GC11124@thunk.org>
In-Reply-To: <CAGK7Mr6dss7BF-srQ3SqeZe2hAe9nS07fGe--ka1rvC5hXvbSA@mail.gmail.com>

On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote:

Show 5 quoted lines

> 
> I agree. The "stage area" is a very important concept in git, why not
> talk git commands that refers to it? Then we could add flags like
> --new-files or --deleted-files for better granularity than the current
> --all flag.

One caution: The term "stage/staged" is already a little overloaded. We generally use the word "staged" to refer to changes that are in the index, but the term "stage" as a noun generally refers to referencing the different versions of a file during a merge operation (cf "git ls-files --stage").

> I think starting by documenting the issues is a good idea, maybe on a
> wiki, and start some draft of a proposed solution that would improve
> in an iterative process.

And it would be nice if the issues were discussed in a way that acknowledged that all changes have tradeoffs, both positive and negative, and to clearly articulate whether the concern is just someone going "uh, 'index' is a wierd term", but once they learn it, it's pretty clear, versus a case where there is continuous confusion due to overloaded meanings, or for people for whom English might not be the first language.

And most importantly, to avoid rheteroic. In fact, given that strong use of rhetoric is often used to disguise a weakness of a position that can't be defended using logic and data, someone who tries to win arguments using the "last post wins" style of discourse, and a heavy use of rhetoric, may find that people just simply decide that it's a better use of their time not to engage and to just kill the entire thread.

Regards,

						- Ted