From: Martin Fick <mfick@codeaurora.org>
To: Junio C Hamano <junio@pobox.com>
Cc: Pete Harlan <pgit@pcharlan.com>,
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 16:43:22 -0700 [thread overview]
Message-ID: <201201161643.23211.mfick@codeaurora.org> (raw)
In-Reply-To: <7v62gbussz.fsf@alter.siamese.dyndns.org>
On Monday, January 16, 2012 04:33:00 pm Junio C Hamano
wrote:
> With your suggestion, they need to export
> "GIT_MERGE_EDIT=0" today, and they will need to update
> again to export "GIT_MERGE_SOMETHINGELSE=0" when such an
> incompatible change comes.
>
> With a single "GIT_MERGE_LEGACY=YesPlease", they can be
> future-proofed today and will not be affected when we
> make another incompatible change.
>
> So I am not sure why separating the big-red-switch into
> smaller pieces would be an improvement, especially wnen
> the scripts that want to specify finer-grained control
> of features can use "--[no-]edit" options to explicitly
> ask for it.
Then, what would I do if I write a script which uses the new
edit functionality (without even being aware that there was
an old way) and you introduce a new incompatibility? I
can't turn on GIT_MERGE_LEGACY then since it would revert to
behavior which my script would not expect (since it was
written after the current incompatibility, but before the
new one)!
-Martin
next prev parent reply other threads:[~2012-01-16 23:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-09 7:37 Regulator updates for 3.3 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:14 ` Phil Hord
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 [this message]
2012-01-17 5:33 ` Pete Harlan
2012-01-17 6:13 ` Junio C Hamano
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=201201161643.23211.mfick@codeaurora.org \
--to=mfick@codeaurora.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=git@vger.kernel.org \
--cc=junio@pobox.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.