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

Re: [PATCH] do not set GIT_TEST_MAINT_SCHEDULER where it does not matter

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Mar 29, 2024, 02:43 UTC
Message-ID
<CAPig+cStHRX-wZKwdcO33wCjd4UU3MO-rVisyOFZ1vPbGaN51Q@mail.gmail.com>
In-Reply-To
<xmqqmsqhsvwk.fsf@gitster.g>
On Thu, Mar 28, 2024 at 8:51 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> 31345d55 (maintenance: extract platform-specific scheduling,
> 2020-11-24) added code to t/test-lib.sh for everybody to set
> GIT_TEST_MAINT_SCHEDULER to a "safe" value and instructed the test
> writers to set the variable locally when their test wants to check
> the scheduler integration.
>
> But it did so without "export GIT_TEST_MAINT_SCHEDULER", so the
> setting does not seem to have any effect anyway.  Instead of setting
> it to a "safe" value, just unset it.

I agree that the missing `export` makes this a do-nothing assignment. In fact, that problem traces back to the original 2fec604f8d (maintenance: add start/stop subcommands, 2020-09-11).

Show 13 quoted lines
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> diff --git c/t/test-lib.sh w/t/test-lib.sh
> @@ -1959,9 +1959,9 @@ test_lazy_prereq DEFAULT_REPO_FORMAT '
>  # Ensure that no test accidentally triggers a Git command
>  # that runs the actual maintenance scheduler, affecting a user's
>  # system permanently.
> -# Tests that verify the scheduler integration must set this locally
> -# to avoid errors.
> -GIT_TEST_MAINT_SCHEDULER="none:exit 1"
> +# Tests that verify the scheduler integration must set and
> +# export this variable locally.
> +sane_unset GIT_TEST_MAINT_SCHEDULER

Clearly the idea was to protect the scheduler-configuration of the person running the test in the event that the test author forgot to set GIT_TEST_MAINT_SCHEDULER to one of the legitimate "testing values" before invoking a "destructive" command, such as `git maintenance start`. By defaulting to `none:exit 1`, the problem would be caught and reported before any damage could be done to the configuration of the person running the tests.

So, I'm somewhat skeptical of the new direction of simply unsetting GIT_TEST_MAINT_SCHEDULER since that outright removes the intended protection. I'd have expected this problem to be addressed by exporting GIT_TEST_MAINT_SCHEDULER, not by making it easier for an absent-minded test author to break his or her own configuration.

Having said that, it you do want to go the route of eliminating the (intended) protection altogether, I have a couple additional observations:

First, this change requires a corresponding update to the lead-in comment ("Ensure that no test accidentally triggers a Git command that runs the actual maintenance scheduler, affecting a user's system permanently.") since it renders that comment incorrect.

Second, it seems very unlikely that GIT_TEST_MAINT_SCHEDULER will be set in the user's environment anyhow before running the tests, so unsetting it here seems unnecessary and pointless. Instead, a cleaner approach would be to simply remove the entire hunk in t/test-lib.sh dealing with GIT_TEST_MAINT_SCHEDULER, including the comment.

Previous: Junio C HamanoNext: Junio C Hamano
Message 2 of 5 in “do not set GIT_TEST_MAINT_SCHEDULER where it does not matter”
  1. do not set GIT_TEST_MAINT_SCHEDULER where it does not matterJunio C Hamano, Mar 29, 2024
  2. Eric SunshineMar 29, 2024
  3. Junio C HamanoMar 29, 2024
  4. test-lib: fix non-functioning GIT_TEST_MAINT_SCHEDULER fallbackEric Sunshine, Mar 29, 2024
  5. Eric SunshineMar 31, 2024

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.