[PATCH] t5601: exercise clones with "includeIf.*.onbranch"

It was reported that git-clone(1) started to fail in Git v2.44 when cloning via HTTPS when the config contains an "includeIf.*.onbranch" condition:

    $ git clone https://example.com/repo.git
    Cloning into 'repo'...
    BUG: refs.c:2083: reference backend is unknown
    error: git-remote-https died of signal 6

This regression was bisected to 0fcc285c5e (refs: refactor logic to look up storage backends, 2023-12-29). This commit tightens the logic to look up ref backends such that we now die when the backend has not yet been detected by reading the gitconfig.

Now on its own, this commit wouldn't have caused the failure. But in 18c9cb7524 (builtin/clone: create the refdb with the correct object format, 2023-12-12) we have also changed how git-clone(1) initializes the refdb such that it happens after the remote helper is spawned, which is required so that we can first learn about the object format used by the remote repository before initializing the refdb. Starting with this change, the remote helper will be unable to detect the repository right from the start and thus have an unconfigured ref backend. Consequently, when we try to resolve the "includeIf.*.onbranch" condition, we will now fail to look up the refdb and die.

This regression has already been fixed via 199f44cb2e (builtin/clone: allow remote helpers to detect repo, 2024-02-27), where we now pre-initialize a partial refdb so that the remote helper can detect the repository right from the start. But it's clear that we're lacking test coverage of this functionality.

Add a test to avoid regressing in the future. Note that this test stops short of defining the desired behaviour for the "onbranch" condition during a clone. It's not quite clear how exactly it should behave, so this is a leftover bit for the future.

Reported-by: Angelo Dureghello <angelo@kernel-space.org>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 t/t5601-clone.sh | 12 ++++++++++++
 1 file changed, 12 insertions(+)