Pete Harlan [off-list ref] writes:
On 01/10/2012 10:59 PM, Junio C Hamano wrote:
quoted
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.
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
On 01/16/2012 03:33 PM, Junio C Hamano wrote:
Pete Harlan [off-list ref] writes:
quoted
On 01/10/2012 10:59 PM, Junio C Hamano wrote:
quoted
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.
Which is a good thing, because maybe they started using Git after the
current proposed change (which they like), and what you see as new
becomes their "legacy" behavior. If you change something after that,
you can't use GIT_MERGE_LEGACY=yes for that one also because which
legacy is it preserving?
In general, naming configuration variables "DO_IT_<THIS_WAY>" instead
of "DO_IT_THE_OLD_WAY" is better because it's self-documenting. The
only time I think I'd prefer "LEGACY" is if you're planning on
deprecating and removing it eventually and you want to indicate
something to that effect in the name.
--
Pete Harlan
pgit@pcharlan.com