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: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120109073727.GF22134@opensource.wolfsonmicro.com>
[not found] ` <CA+55aFyhoh0rT_ujuE1w3RpuR7kqivYFwPpm66VC-xtq1PiGUQ@mail.gmail.com>
[not found] ` <20120110184530.GE7164@opensource.wolfsonmicro.com>
[not found] ` <CA+55aFxXb7wqfrpozS6iH0k25y-+Uy8_Tavv59JXMhaWrjXLaw@mail.gmail.com>
[not found] ` <20120110222711.GK7164@opensource.wolfsonmicro.com>
2012-01-10 22:54 ` Regulator updates for 3.3 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).