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

Re: What's cooking in git.git (Aug 2021, #02; Tue, 3)

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 5, 2021, 02:08 UTC
Message-ID
<xmqq4kc4myme.fsf@gitster.g>
In-Reply-To
<87fsvon5xm.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 7 quoted lines
> How would it be forgotten? If you introduce tests like the ones changed
> in 1/3 of the series and expect git to pay attention to COLUMNS you'll
> find that they won't work, because if you set COLUMNS=123 we won't take
> it over the GIT_TEST_COLUMNS=80 set in test-lib.sh.
> ...
> ...I'd be happy to remove the helper if Junio would take that version of
> the patch; :)

FWIW, I didn't *request* it; the resulting test scripts that set and unset both the standard COLUMNS and another test-only environment variable looked typo-prone and hard to read, and that is why I suggested to hide that behind a helper.

If we do not have to add a test-only enviroment variable at all, I do not see the reason why we need a helper.

Show 7 quoted lines
> By narrowly targeting a fix at one specific shell's cleverness around
> COLUMNS we'll leave open a window where we'll fail on other shells if
> they introduce similar cleverness.
>
> It hardly seems like a stretch that once bash starts doing that sort of
> thing other shells might think to follow suit, and all have their own
> non-standard way to turn it off.

Hmph. Wouldn't the same argument apply to the much simpler single liner "shopt -u" solution? When writing new tests, there is nothing to remember, and a new shell that needs a different trick to defeat the auto-COLUMNS would be detected quickly by running the tests in a terminal whose width is different from 80, no?

> You also didn't address the other rationale for it, namely that it's
> also future-proofing us for submarine breakages in non-git programs
> which'll understand the new COLUMNS=10, but not GIT_TEST_COLUMNS=80.
Isn't that another downside of the approach you are advocating?

If we make Git rely on GIT_TEST_COLUMNS, we may honor it while everybody else ignores it. If we only have to deal with COLUMNS like everybody else does, Git and other tools that are used in our tests will be affected the same way by overly-clever shells, no?

Previous: Ævar Arnfjörð BjarmasonNext: Ævar Arnfjörð Bjarmason
Message 11 of 18 in “What's cooking in git.git (Aug 2021, #02; Tue, 3)”
  1. Junio C HamanoAug 4, 2021
  2. Ævar Arnfjörð BjarmasonAug 4, 2021
  3. Junio C HamanoAug 4, 2021
  4. Ævar Arnfjörð BjarmasonAug 4, 2021
  5. Junio C HamanoAug 4, 2021
  6. Ævar Arnfjörð BjarmasonAug 4, 2021
  7. Junio C HamanoAug 4, 2021
  8. SZEDER GáborAug 4, 2021
  9. SZEDER GáborAug 4, 2021
  10. Ævar Arnfjörð BjarmasonAug 4, 2021
  11. Junio C HamanoAug 5, 2021
  12. Ævar Arnfjörð BjarmasonAug 5, 2021
  13. SZEDER GáborAug 30, 2021
  14. SZEDER GáborAug 4, 2021
  15. Derrick StoleeAug 4, 2021
  16. Jeff KingAug 4, 2021
  17. Phillip WoodAug 5, 2021
  18. Taylor BlauAug 5, 2021

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.