From: Philip Oakley <philipoakley@iee.org>
Date: Thu, 17 Oct 2013 19:48:46 GMT
Subject: Re: [PATCH v3] Add core.mode configuration
Message-ID: <360782C85A2E4C9091EAD1E85D69680C@PhilipOakley>
In-Reply-To: <20131016230634.GO9464@google.com>

From: "Jonathan Nieder" <jrnieder@gmail.com>
> Philip Oakley wrote:
>
>> Would this be a good time to suggest a specific wording should be
>> proposed (or a reminder of what was proposed repeated) for the
>> documentation of this option. It will be the documentation that
>> users will refer to when they need to know, rather than the list
>> discussions.
>
> It's not clear to me that this config item is a good idea.
>

My point was that the arguments had been rehearsed and explored, and 
that it was possibly a suitable time for Filippe to update any commit 
message and config item documentation so that the proposal can be 
judged.

> What is the intended use?  If someone wants to test that their scripts
> will continue to work with git 2.0, wouldn't testing a 2.0 release
> candidate (or the current state of the 'jch' branch until one exists)
> be the simplest way to do that?  If someone just likes the proposed
> behavior changes and wants to start using them right away, maybe we
> can help them by releasing 2.0 sooner ;-), or by advertising the
> fairly simple changes in commandline usage to get the new behaviors:
>

In terms of moving forward, there needs to be a balance between being 
stuck in the old world of the 60's, and being projected into the bright 
new world of the 20's (OK so I have exaggerated a bit there ;-). It's 
always been a case of different strokes for different folks - there will 
be folk who will try such an option (in an honest manner), who may not 
be aware of branches that are outside of the regular pu / next / master 
/ maint branches which the project publicises.

Rather than letting the email discussion degenerate by going round in 
circles to the usual end point, having a clarifying proposal (hopefully 
well balanced) would at least allow a cleaner understanding and 
decision.

> Instead of "git add", use "git add -A".
>
> When using "git add -u" or "git add -A" from a subdirectory
> of the toplevel, specify "git add -u ." explicitly unless you
> want it to apply to the whole tree (in which case use
> "git add -u :/").
>
> Instead of letting "git push" guess, name the branch you
> want to push: "git push origin master".  Or set
> '[push] default = simple' in your configuration.
>
> Pass --prefix to "git svn clone".
>
> The downside of configuration like the proposed core.next is that it
> is hard to explain ("What do you mean that I can't roll back to the
> pre-2.0 behavior in Git 2.0 by setting this configuration setting to
> an appropriate value?"), users or scripts can rely on it, and
> configuration variables tend to accumulate and never be removed.  If
> we really want a run-time switch for this, I suspect an appropriately
> named environment variable would work better, since we have a history
> of being able to remove those without alarming people.
>
> My two cents,
> Jonathan
>