Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Krzysztof Mazur <krzysiek@podlesie.net>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3] Add core.mode configuration
Date: Tue, 15 Oct 2013 15:33:27 +0200
Message-ID: <20131015133327.GA22723@shrek.podlesie.net> (raw)
In-Reply-To: <525d35e766ad4_55661275e7426@nysa.notmuch>

On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote:
> Krzysztof Mazur wrote:
> > 
> > But with core.mode = next after upgrade you may experience incompatible
> > change without any warning.
> 
> Yes, and that is actually what the user wants. I mean, why would the user set
> core.mode=next, if the user doesn't want to experencie incompatible changes? A
> user that sets this mode is expecting incompatible changes, and will be willing
> to test them, and report back if there's any problem with them.

With your patch, because it's the only way to have 'git add' v2.0.
But if another git v2.0 incompatible change will be added it will not
be warned, because with core.mode=next he decided to enable also
future changes and that's why I would never set that.

> 
> > I think it's better to keep the old behavior by default and warn the user if
> > with new behavior the result might be different. So the user:
> > 
> > 	a) knows about the change
> > 
> > 	b) may set appropriate option to enable the new default or keep
> > 	   the old behavior and disable the warning
> > 
> > 	c) may report that he does not like that change
> 
> But that's what we are doing already. Look at the test I wrote, it's testing
> the warnings for the current version of Git.

With pull.default we did that, but with git add v2.0 now we only warn
the user. With your patch he can enable new git add (and disable warning),
but he also enables future incompatible changes and disables
warnings for such changes. He also cannot keep the old behaviour and
disable the warning.

> 
> > I don't see the change in "git add" as an improvement, because
> > removing files with "git add" IMHO is more confusing than ignoring
> > such files. Maybe introducing new command - "git update" for instance -
> > which is equivalent to new "git add" and teaching new users to use it
> > instead of "git add" is better.
> 
> I agree. At first I simply ignored the changes because I didn't have the
> patience to figure out what exactly did they mean. Now I was forced to
> understand them to write this patch, and I'm also forcing myself to use this
> behavior.
> 
> 'git add' removing files is counter-intutive, 'git stage' (currently an alias
> to 'git add') might make more sense.

Yeah, 'git stage' as an alias to 'git add -A' is much more intuitive.

Krzysiek

  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 [this message]
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
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=20131015133327.GA22723@shrek.podlesie.net \
    --to=krzysiek@podlesie.net \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.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