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


\
 
 \ /
  Last update: 2012-01-17 00:45    [W:0.056 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site