From: Philippe Blain <levraiphilippeblain@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Philippe Blain via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Luke Shumaker <lukeshu@datawire.io>,
Thomas Koutcher <thomas.koutcher@online.fr>,
James Limbouris <james@digitalmatter.com>
Subject: Re: [PATCH 1/9] test-lib-functions: mark 'test_commit' variables as 'local'
Date: Wed, 26 Oct 2022 17:21:31 -0400 [thread overview]
Message-ID: <3a41e02f-c1fb-64ed-377b-4e4168f2adae@gmail.com> (raw)
In-Reply-To: <xmqq8rl8kht3.fsf@gitster.g>
Hi Junio,
Le 2022-10-21 à 17:06, Junio C Hamano a écrit :
> "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Philippe Blain <levraiphilippeblain@gmail.com>
>>
>> Some variables in 'test_commit' have names that are common enough that
>> it is very likely that test authors might use them in a test. If they do
>> so and use 'test_commit' between setting such a variable and using it,
>> the variable value from 'test_commit' will leak back into the test and
>> most likely break it.
>>
>> Prevent that by marking all variables in 'test_commit' as 'local'. This
>> allow a subsequent commit to use a 'tag' variable.
>
> This is the right thing to do, if done onn day 1 of the project, and
> it is the right thing to do for the longer term health of the
> project. But it is a bit scary thing to do in the middle.
>
> I wonder if there is an easy way to detect that a set of callers of
> test_commit are relying on the fact that calling test_commit without
> passing --author option cleared their $author variable (similarly
> for other variables that are cleared or set to a known value as a
> side effect of calling test_commit). If their correctness depends
> on $author becoming empty after calling the script today, they will
> get broken by this change.
>
> While it is OK to argue that they deserve it, we would have to be
> finding and fixing them ourselves after all.
Isn't the fact that the test suite passes with this change enough for us
to be confident that nothing is broken by it ?
In any case, I did a quick manual grep of each of the variables and could not
find a test that uses these names, so I think we are safe.
Thanks,
Philippe.
next prev parent reply other threads:[~2022-10-26 21:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 15:13 [PATCH 0/9] subtree: fix split and merge after annotated tag was squash-merged Philippe Blain via GitGitGadget
2022-10-21 15:13 ` [PATCH 1/9] test-lib-functions: mark 'test_commit' variables as 'local' Philippe Blain via GitGitGadget
2022-10-21 21:06 ` Junio C Hamano
2022-10-26 21:21 ` Philippe Blain [this message]
2022-10-26 21:38 ` Junio C Hamano
2022-10-21 15:13 ` [PATCH 2/9] subtree: use 'git rev-parse --verify [--quiet]' for better error messages Philippe Blain via GitGitGadget
2022-10-21 15:13 ` [PATCH 3/9] subtree: add 'die_incompatible_opt' function to reduce duplication Philippe Blain via GitGitGadget
2022-10-21 16:22 ` Ævar Arnfjörð Bjarmason
2022-10-26 21:23 ` Philippe Blain
2022-10-21 15:13 ` [PATCH 4/9] subtree: prefix die messages with 'fatal' Philippe Blain via GitGitGadget
2022-10-21 16:30 ` Ævar Arnfjörð Bjarmason
2022-10-26 21:24 ` Philippe Blain
2022-10-21 15:13 ` [PATCH 5/9] subtree: define a variable before its first use in 'find_latest_squash' Philippe Blain via GitGitGadget
2022-10-21 15:13 ` [PATCH 6/9] subtree: use named variables instead of "$@" in cmd_pull Philippe Blain via GitGitGadget
2022-10-21 15:13 ` [PATCH 7/9] subtree: process 'git-subtree-split' trailer in separate function Philippe Blain via GitGitGadget
2022-10-21 15:13 ` [PATCH 8/9] subtree: fix squash merging after annotated tag was squashed merged Philippe Blain via GitGitGadget
2022-10-21 15:13 ` [PATCH 9/9] subtree: fix split " Philippe Blain via GitGitGadget
2022-10-21 16:37 ` Ævar Arnfjörð Bjarmason
2022-10-21 18:24 ` Eric Sunshine
2022-10-26 21:26 ` Philippe Blain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a41e02f-c1fb-64ed-377b-4e4168f2adae@gmail.com \
--to=levraiphilippeblain@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=james@digitalmatter.com \
--cc=lukeshu@datawire.io \
--cc=thomas.koutcher@online.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.