[lkml]   [2012]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Re* Regulator updates for 3.3
    Pete Harlan <> 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.


    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.

     \ /
      Last update: 2012-01-17 00:35    [W:0.020 / U:74.132 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site