Re: What is missing from Git v2.0

From: Philippe Vaucher <philippe.vaucher@gmail.com>
Date: Apr 25, 2014, 15:54 UTC
Message-ID: <CAGK7Mr74TK4x7WYnmWyRUj_Aga0CHbyFNyZGZdu6eubtwahBXg@mail.gmail.com>
In-Reply-To: <20140425144054.GA6230@thunk.org>

Show 7 quoted lines

>> 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 renaming one of a term also has costs, especially if it is one
> that is in use in large amounts of documentation, both in the git man
> pages, and in web pages across the web.

It's just impossible to change terms and have previous documentation still be valid. Sure, you can list it in the "cons" section as an argument, but it's not very convincing in itself because it applies to pretty much any interface changes. I think the main idea is to _improve_ the interface, which means rename things so it is more consistent and so concepts are easier for new comers to grasp. We could still support old terms for a while and eventually deprecate them.

> www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q

I think this comparison is a bit bogus, searching for "git stage" yields more accurate results, we can see the searches are related:

http://www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index%2C%20git%20stage&cmpt=q

Show 11 quoted lines

>> 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.
>
> Voting is not a good way to do software development.  That way lies
> people wanting to whip up clueless folks using rhetoric (exhibit one:
> Fox News) to "vote" and so it's not necessarily the best way to make
> thoughtful decisions.  Using hard data, including possibly formal UX
> experiments, is a much better way to make such decisions.

Interesting, but then who's to say which data is more important than anothers? For example, I consider improving the interface to be more important than having old documentation on blogs/tutorial for a while until people catch up, but maybe you consider old documentation to be more important... who decides what really counts? I guess it's a mix of general consensus and old timers credibility.

Anyway, having some data as a list of pros/cons would greatly simplify the debate.

Philippe