Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Philip Oakley <philipoakley@iee.org>
Cc: John Szakmeister <john@szakmeister.net>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	Krzysztof Mazur <krzysiek@podlesie.net>,
	git@vger.kernel.org
Subject: Re: [PATCH v3] Add core.mode configuration
Date: Wed, 16 Oct 2013 16:06:34 -0700
Message-ID: <20131016230634.GO9464@google.com> (raw)
In-Reply-To: <8629441933A94862982C5CDD6BF47690@PhilipOakley>

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.

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:

	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

  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 [this message]
2013-10-17 19:48                           ` Philip Oakley
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20131016230634.GO9464@google.com \
    --to=jrnieder@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=john@szakmeister.net \
    --cc=krzysiek@podlesie.net \
    --cc=philipoakley@iee.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 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/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git