On Thu Oct 17, 2024 at 22:45, Bence Ferdinandy <bence@xxxxxxxxxxxxxx> wrote: > Hi, > > I'm looking at why the set-head series (cf.: > https://lore.kernel.org/git/20241014225431.1394565-1-bence@xxxxxxxxxxxxxx/) > breaks the CI. The problem stems from the local test repositories being set up > differently from that of the CI. > > I ran both the CI and a local test on current master with the following patch > applied on top, i.e. I print all remote refs and intentionally break the test > so that the result is easy to get from the CI: > > diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh > index 532035933f..d625a3a8b6 100755 > --- a/t/t5505-remote.sh > +++ b/t/t5505-remote.sh > @@ -724,8 +724,11 @@ test_expect_success 'update' ' > cd one && > git remote add drosophila ../two && > git remote add apis ../mirror && > + git ls-remote drosophila && > + git ls-remote apis && > git remote update && > git branch -r >output && > + echo "force error" >output && > test_cmp expect output > ) > ' > > The CI gives the following output: > https://github.com/ferdinandyb/git/actions/runs/11392309625/job/31698105287 > > > + git ls-remote drosophila > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 HEAD > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/another > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > + git ls-remote apis > 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 HEAD > 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > > > While from ./t5505-remote.sh -v I get: > > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 HEAD > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/another > 9d34b142e42f6b3dbab46dd4b9bc515e0ab16101 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > 6329a3ca5268a0b28a1dc29b602e8b72a0bc1b37 refs/heads/main > 2ce9c504874e3f0ce77f83c0bb0b1024c7a6387f refs/heads/side > > Since `git remote update` here is essentially running `git fetch --multiple --all`, > with the set-head series applied we're attempting to set HEAD for both > remotes. Obviously, this fails locally and succeeds in the CI, which is > actually the patch series behaving as intended, but obviously a drift between > the local and the CI testing environments. > > I'm probably too tired right now, but I don't see how or what could make the > mirror repo be different depending on having it locally or in the CI ... At > least I know it's definitely not my patch series :) Does anyone have an idea > what to try and look into? > > I guess ideally the fix for this would be added to the beginning of the series > so we can continue with both local and CI tests working. (Although it could be > marked as a know breakage as well, not so elegant). > > Thanks, > Bence I found the issue. It comes down to the CI running with export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main while this not being set in ./t5505-remote.sh. Now the bandaid here is adding this to t5505, but it may not be the solution. The problem essentially is that `git remote add --mirror -f origin [somerepo]` does not update HEAD in a bare repository. Consider the following: git config --global init.defaultBranch mypreference mkdir one cd one git init -b notmypreference git commit -m "initial commit" --allow-empty cd .. mkdir mirror cd mirror git init --bare git remote add --mirror -f origin ../one cat HEAD You'll see HEAD is ref: refs/heads/mypreference. Continuing cd .. mkdir r_one cd r_one git init git remote add origin ../mirror git ls-remote We arrive at a single reference pointing to refs/heads/notmypreference. If we do the same exercise, but instead setting up repo "one" with `git init -b mypreference` running ls-remote "r_one" will actually also yield a HEAD reference. I'm not sure if it should or not, so for now I'll just make sure that ./t5505-remote.sh uses "main" as the default branch. Best, Bence -- bence.ferdinandy.com