git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Re* Regulator updates for 3.3

From
PHPete Harlan <pgit@pcharlan.com>
Date
Jan 17, 2012, 05:33 UTC
Message-ID
<4F15080C.6060004@pcharlan.com>
In-Reply-To
<7v62gbussz.fsf@alter.siamese.dyndns.org>
On 01/16/2012 03:33 PM, Junio C Hamano wrote:
Show 24 quoted lines
> 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.

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

Previous: Martin FickNext: Junio C Hamano
Message 13 of 20 in “Re: Regulator updates for 3.3”
  1. Linus TorvaldsJan 10, 2012
  2. Mark BrownJan 10, 2012
  3. Junio C HamanoJan 11, 2012
  4. Linus TorvaldsJan 11, 2012
  5. Junio C HamanoJan 11, 2012
  6. Linus TorvaldsJan 11, 2012
  7. Re* Regulator updates for 3.3Junio C Hamano, Jan 11, 2012
  8. Phil HordJan 11, 2012
  9. Linus TorvaldsJan 11, 2012
  10. Pete HarlanJan 16, 2012
  11. Junio C HamanoJan 16, 2012
  12. Martin FickJan 16, 2012
  13. Pete HarlanJan 17, 2012
  14. Junio C HamanoJan 17, 2012
  15. Linus TorvaldsJan 11, 2012
  16. Paul GortmakerJan 11, 2012
  17. Junio C HamanoJan 13, 2012
  18. Nguyen Thai Ngoc DuyJan 13, 2012
  19. Linus TorvaldsJan 13, 2012
  20. Miles BaderJan 17, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.