Messages in this thread |  | | | From | Junio C Hamano <> | | Subject | Re: Re* Regulator updates for 3.3 | | Date | Mon, 16 Jan 2012 15:33:00 -0800 |
| |
Pete Harlan <pgit@pcharlan.com> writes:
> On 01/10/2012 10:59 PM, Junio C Hamano wrote: >> There may be existing scripts that leave the standard input and the >> standard output of the "git merge" connected to whatever environment the >> scripts were started, and such invocation might trigger the above >> "interactive session" heuristics. Such scripts can export GIT_MERGE_LEGACY >> environment variable set to "yes" to force the traditional behaviour. > > The name GIT_MERGE_LEGACY gives no clue about what flavor of legacy > merge behavior is being enabled. Something like GIT_MERGE_LEGACY_EDIT > might be clearer, or perhaps just have GIT_MERGE_EDIT=0 to get the old > behavior without reference to whether or not that behavior is > considered legacy.
Hrm.
The only case your suggestion may make a difference would be when we find another earlier UI mistake we would want to correct in a backward incompatible way that affects _existing_ scripts.
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.
|  |