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