Re: [PATCH v8] builtin/clone.c: add --reject-shallow option

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Tue, 30 Mar 2021, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > ... repository has been initialized. Note that my suggestion still works with
> > that: if either the original config, or the new config set
> > `clone.rejectShallow`, it is picked up correctly, with the latter
> > overriding the former if both configs want to set it.
>
> All four combinations ("set it to true" vs "set it to false" makes
> two, and before and after doubles that to four)?

I don't think we need to test all four combinations, that's part of my
point. We only need to verify that we can reject a shallow clone, and that
we can allow it, and that the command-line option overrides the config
option. That's three ;-)

> >> diff --git a/t/t5606-clone-options.sh b/t/t5606-clone-options.sh
> >> index 428b0aac93fa..de1cd85983ed 100755
> >> --- a/t/t5606-clone-options.sh
> >> +++ b/t/t5606-clone-options.sh
> >> @@ -5,6 +5,8 @@ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
> >>  export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
> >>
> >>  . ./test-lib.sh
> >> +. "$TEST_DIRECTORY"/lib-httpd.sh
> >> +start_httpd
> >
> > That's not good. What happens if there is no `httpd`? Then the rest of the
> > tests are either skipped, or if `GIT_TEST_HTTPD` is set to `true`, we
> > fail. The failure is intentional, but the skipping is not. There are many
> > tests in t5606 that do not require a running HTTP daemon, and we should
> > not skip them (for example, in our CI runs, there are quite a few jobs
> > that run without any working `httpd`).
> >
> > A much better alternative, I think, would be to move those new test cases
> > that require `httpd` to be running to t5601 (which _already_ calls
> > `start_httpd`, near the end, so as to not skip any tests that do not
> > require `httpd`).
>
> Or move the tests that require httpd, and use of httpd library, to
> the end of this script.

In the interest of saving some time during the already-quite-long test
runs, I would recommend piggy-backing onto a script that _already_ spins
up its own Apache server.

Thanks,
Dscho