>> 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 agree, but I think it's better than "index" tho. That one is heavily
overloaded and easily confused with other meaning in other softwares.

>> 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.

Yes, of course there should be a list of both positive and negative
tradeoffs. But I think the "overloaded" argument can be easily solved
by renaming one of the overloads.

> 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.

Unfortunately yes, I see many people being silly in order to win
arguments, both in the pro-changes and against-changes side of the
discussion. I'd be much simpler to simply gather arguments on some
wiki and eventually do a vote when the list is complete about the
proposed change.

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

Reply via email to