Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: John Szakmeister <john@szakmeister.net>
To: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: Felipe Contreras <felipe.contreras@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v3] Add core.mode configuration
Date: Tue, 15 Oct 2013 12:59:48 -0400
Message-ID: <CAEBDL5V8wfbQTZ5do-UMRpSsxRN8bFaHVnG7kRNfP0t+oYbfNg@mail.gmail.com> (raw)
In-Reply-To: <20131015145139.GA3977@shrek.podlesie.net>

On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur <krzysiek@podlesie.net> wrote:
> On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote:
>> Krzysztof Mazur wrote:
>> > 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.
>>
>> Yeah, but that's not what I'm suggesting. I suggested to have *both* a
>> fined-tunned way to have this behavior, say core.addremove = true, and a way to
>> enable *all* v2.0 behaviors (core.mode = next).
>
> I'm just not sure if a lot of users would use core.mode=next, because
> of possible different behavior without any warning. Maybe we should also
> add core.mode=next-warn that changes defaults like next but keeps warnings
> enabled until the user accepts that change by setting appropriate
> config option? That's safer than next (at least for interactive use) and
> maybe more users would use that, but I don't think that's worth adding.

I like the idea that we could kick git into a mode that applies the
behaviors we're talking about having in 2.0, but I'm concerned about
one aspect of it.  Not having these behaviors until 2.0 hits means
we're free to renege on our decisions in favor of something better, or
to pull out a bad idea.  But once we insert this knob, I don't know
that we have the same ability.  Once people realize it's there and
start using it, it gets harder to back out.  I guess we could maintain
the stance that "the features are not concrete yet," or something like
that, but I think people would still get upset if something changes
out from under them.

So, at the end of the day, I'm just not sure it's worthwhile to have.

-John

  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 [this message]
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=CAEBDL5V8wfbQTZ5do-UMRpSsxRN8bFaHVnG7kRNfP0t+oYbfNg@mail.gmail.com \
    --to=john@szakmeister.net \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=krzysiek@podlesie.net \
    /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