Git Mailing List Archive on
 help / color / Atom feed
From: "Philip Oakley" <>
To: "Jonathan Nieder" <>
Cc: "John Szakmeister" <>,
	"Felipe Contreras" <>,
	"Krzysztof Mazur" <>, <>
Subject: Re: [PATCH v3] Add core.mode configuration
Date: Thu, 17 Oct 2013 20:48:46 +0100
Message-ID: <360782C85A2E4C9091EAD1E85D69680C@PhilipOakley> (raw)
In-Reply-To: <>

From: "Jonathan Nieder" <>
> 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 

> 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 

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

  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-12  7:04 Felipe Contreras
2013-10-14 20:59 ` Krzysztof Mazur
2013-10-14 21:35   ` Felipe Contreras
2013-10-15 12:35     ` Krzysztof Mazur
2013-10-15 12:32       ` Felipe Contreras
2013-10-15 13:33         ` Krzysztof Mazur
2013-10-15 13:29           ` Felipe Contreras
2013-10-15 14:51             ` Krzysztof Mazur
2013-10-15 16:59               ` John Szakmeister
2013-10-16  3:55                 ` Felipe Contreras
2013-10-16  7:09                   ` Krzysztof Mazur
2013-10-16 19:31                     ` Felipe Contreras
2013-10-16 10:54                   ` John Szakmeister
2013-10-16 15:11                     ` John Szakmeister
2013-10-16 19:57                       ` Felipe Contreras
2013-10-16 19:32                     ` Felipe Contreras
2013-10-16 22:02                       ` Philip Oakley
2013-10-16 23:06                         ` Jonathan Nieder
2013-10-17 19:48                           ` Philip Oakley [this message]
2013-10-17 21:08                           ` Felipe Contreras
2013-10-15 18:51               ` Felipe Contreras
2013-10-15 22:01                 ` Krzysztof Mazur
2013-10-16  4:03                   ` Felipe Contreras
2013-10-16  6:34                     ` Krzysztof Mazur
2013-10-16 19:28                       ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=360782C85A2E4C9091EAD1E85D69680C@PhilipOakley \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Mailing List Archive on

Archives are clonable:
	git clone --mirror git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ \
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone