From: Junio C Hamano <gitster@pobox.com>
To: Pete Harlan <pgit@pcharlan.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Liam Girdwood <lrg@ti.com>,
linux-kernel@vger.kernel.org,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Re* Regulator updates for 3.3
Date: Mon, 16 Jan 2012 22:13:02 -0800 [thread overview]
Message-ID: <7vboq2uaa9.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4F15080C.6060004@pcharlan.com> (Pete Harlan's message of "Mon, 16 Jan 2012 21:33:00 -0800")
Pete Harlan <pgit@pcharlan.com> writes:
> ... The
> only time I think I'd prefer "LEGACY" is if you're planning on
> deprecating and removing it eventually and you want to indicate
> something to that effect in the name.
The discussion that led to the naming of that LEGACY token needs to be
re-read, then. The kind of "LEGACY" you prefer is exactly why the
environment variable is called LEGACY in the patch you are commenting on,
written in response to Linus's suggestion to switch the default, even
though I am not 100% buying it.
Having said that, I think I am wasting my time responding to this thread
during the feature-freeze period for v1.7.9, as I am not a big fan of
switching the default without adequate warning and transition plans, after
getting burned by the "'git-foo' vs 'git foo'" flames back in the v1.6.0
release. We would likely to take a gradual and smoother migration route to
transition, e.g. v1.7.9 to introduce "merge --edit", v1.7.10 to introduce
a configuration variable merge.edit (lack of which gives a warning and an
advice message while defaulting to 'no' to preserve the traditional
behaviour), and finally v1.8.0 (or v2.0) to flip the default to 'yes'
(while the configuration still giving a warning and an advice message)
that "merge --no-edit" can still countermand.
So you have until v1.7.10 to decide a good name for the overriding
environment variable.
next prev parent reply other threads:[~2012-01-17 6:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 7:37 Mark Brown
2012-01-10 18:27 ` Linus Torvalds
2012-01-10 18:45 ` Mark Brown
2012-01-10 19:18 ` Linus Torvalds
2012-01-10 22:27 ` Mark Brown
2012-01-10 22:54 ` Linus Torvalds
2012-01-10 23:17 ` Mark Brown
2012-01-11 2:28 ` Junio C Hamano
2012-01-11 2:47 ` Linus Torvalds
2012-01-11 3:03 ` Junio C Hamano
2012-01-11 3:14 ` Linus Torvalds
2012-01-11 6:59 ` Re* " Junio C Hamano
2012-01-11 16:23 ` Linus Torvalds
2012-01-16 0:14 ` Pete Harlan
2012-01-16 23:33 ` Junio C Hamano
2012-01-16 23:43 ` Martin Fick
2012-01-17 5:33 ` Pete Harlan
2012-01-17 6:13 ` Junio C Hamano [this message]
2012-01-11 3:21 ` Linus Torvalds
2012-01-11 18:40 ` Paul Gortmaker
2012-01-13 19:12 ` [PATCH] merge: Make merge strategy message follow the diffstat Junio C Hamano
2012-01-13 19:27 ` Nguyen Thai Ngoc Duy
2012-01-13 19:49 ` Linus Torvalds
2012-01-17 8:03 ` Miles Bader
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=7vboq2uaa9.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=git@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=pgit@pcharlan.com \
--cc=torvalds@linux-foundation.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®