Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>,
	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: Thu, 17 Oct 2013 16:08:19 -0500
Message-ID: <526051c3c2f07_448145fe74a@nysa.notmuch> (raw)
In-Reply-To: <20131016230634.GO9464@google.com>

Jonathan Nieder wrote:
> 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

There is no 2.0 release candidate, and the window between the first 2.0 rc and
2.0 final is limited, such person might not have the time do such testing in
that window.

Moreover, it's not just to test their scripts, but also their fingers.

> (or the current state of the 'jch' branch until one exists)

That doesn't work for the vast majority of users who do not compile Git.

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

So basically you are advocating for another v1.6 fiasco, where users start
complaining about the new behaviors *after* the release has been made, and
their user experience has been broken. Is that the case?

> , 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".

I don't get why you don't understand something so simple about human nature.
Every teach knows that you don't just give a lecture, even if the student
understands what you explained, most likely (s)he would not learn it until
after doing excercises.

99% of our users have not read the release notes about the 2.0 changes, 98%
will not read that advertizement you just said, 90% of those who read it will
only get noise, and the ones that read and understand it, might change their
minds once they experience it.

That's why in every game conference they don't just explain to you the new
game, they let you play it, only then the end users can give an honest opinion
about the game.

Perhaps it's unfortunate, but our users are human, and that's how humans work.

We don't know if our users would be OK with the 2.0 changes, it's only after
they have given it a try that they can honestly say, and it's better to give
them as much time as possible and make it easier for them to try.

> 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?"),

It is not hard to explain.

core.mode = next enables the proposed behavior for the next major version of
Git (v2.0), which might change. core.mode = current (the default) enables the
behavior of the current version of Git (v1.x).

It is implied that there's no core.mode = previous, but it can be explicitly stated.

> users or scripts can rely on it, and configuration variables tend to
> accumulate and never be removed.

Not this one, because this one makes it clear that is volatile (although
probably not that much).

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

The fact that B has done the job in the past, doesn't mean it would do the job
better than A in the future.

-- 
Felipe Contreras

  parent 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
2013-10-17 21:08                           ` Felipe Contreras [this message]
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=526051c3c2f07_448145fe74a@nysa.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=john@szakmeister.net \
    --cc=jrnieder@gmail.com \
    --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