{"thread":{"id":"61076","subject":"[BUG] cannot git clone with includeif onbranch","startedAt":"2024-03-08T19:33:10Z","lastAt":"2024-03-22T02:15:51Z","messageCount":10,"participants":["Angelo Dureghello","brian m. carlson","rsbecker@nexbridge.com","Patrick Steinhardt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"490265","messageId":"72771da0-a0ef-4fd9-8071-6467cd7b6a6b@kernel-space.org","threadId":"61076","inReplyTo":null,"subject":"[BUG] cannot git clone with includeif onbranch","fromName":"Angelo Dureghello","fromEmail":"angelo@kernel-space.org","sentAt":"2024-03-08T19:25:52Z","receivedAt":"2024-03-08T19:33:10Z","isPatch":false,"sender":{"key":"angelo@kernel-space.org","avatar":null},"body":"Hi,\n\nbelow the bug report, not totally sure this is a bug btw.\n\n---\n\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\nPerform a git clone https with includeif onbranch in the .gitconfig\n\nCreate a .gitconfig\nwith\n[includeIf \"onbranch:wip/pippo/**\"]\n         path = ~/.gitconfig.pippo.inc\n\ngit clone https://github.com/analogdevicesinc/no-OS.git\n\nCloning into 'no-OS'...\nBUG: refs.c:2083: reference backend is unknown\nerror: git-remote-https died of signal 6\n\nWhat did you expect to happen? (Expected behavior)\nProper clone\n\nWhat happened instead? (Actual behavior)\nError above\n\nWhat's different between what you expected and what actually happened?\nI cannot clone\n\nAnything else you want to add:\nI am assuming that cloning is outside from any gitdir so should ingnore\nonbranch.\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.44.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 6.5.0-rc2-devel-00345-gc2782531397f #2 SMP PREEMPT_DYNAMIC \nSun Jul 23 12:25:41 CEST 2023 x86_64\ncompiler info: gnuc: 13.2\nlibc info: glibc: 2.39\n$SHELL (typically, interactive shell): /bin/zsh\n\n\n[Enabled Hooks]\nnot run from a git repository - no hooks to show\n"},{"id":"490266","messageId":"Zetw0I0NHgABR_PX@tapette.crustytoothpaste.net","threadId":"61076","inReplyTo":"72771da0-a0ef-4fd9-8071-6467cd7b6a6b@kernel-space.org","subject":"Re: [BUG] cannot git clone with includeif onbranch","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-03-08T20:10:56Z","receivedAt":"2024-03-08T20:11:16Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-03-08 at 19:25:52, Angelo Dureghello wrote:\n> Hi,\n> \n> below the bug report, not totally sure this is a bug btw.\n> \n> ---\n> \n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n> \n> What did you do before the bug happened? (Steps to reproduce your issue)\n> \n> Perform a git clone https with includeif onbranch in the .gitconfig\n> \n> Create a .gitconfig\n> with\n> [includeIf \"onbranch:wip/pippo/**\"]\n>         path = ~/.gitconfig.pippo.inc\n> \n> git clone https://github.com/analogdevicesinc/no-OS.git\n> \n> Cloning into 'no-OS'...\n> BUG: refs.c:2083: reference backend is unknown\n> error: git-remote-https died of signal 6\n\nThanks for the report.\n\nI can definitely confirm this with a local Git 2.44.0 built out of my\nworking tree.  It seems to trigger as long as there's a `path` entry\nwhether the path exists or not.  It _doesn't_ seem to trigger with a\n`gitdir` check, but does trigger for `onbranch`.  v2.43.0 is not\naffected.\n\nI do definitely think this is a bug.  First of all, we should not\ntrigger BUG conditions, even if the user has done something naughty, so\nwe should fix it for that reason.  Second of all, this seems like a\ncompletely reasonable thing to want to do, and considering it triggers\nfor existing files, and that it worked just fine in v2.43.0, I don't see\na reason we shouldn't have this work.\n\nA bisection[0] leads us to 0fcc285c5e (\"refs: refactor logic to look up\nstorage backends\", 2023-12-29).  I've CCed the author of that commit,\nwho hopefully can provide some more helpful context.\n\nI have some guesses about what's going on here, but I haven't poked\nfurther into the situation, so I'll refrain from speculating for now.\n\n[0] git bisect run sh -c 'make -j12 && cd $TMPDIR && rm -fr no-OS && PATH=\"$HOME/checkouts/git/bin-wrappers:$PATH\" git clone https://github.com/analogdevicesinc/no-OS.git; RET=$?; [ \"$RET\" -eq 128 ] && RET=1; exit $RET'\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"490267","messageId":"d5f9235a-aa27-dc82-8191-c3e4b73ebce9@kernel-space.org","threadId":"61076","inReplyTo":"Zetw0I0NHgABR_PX@tapette.crustytoothpaste.net","subject":"Re: [BUG] cannot git clone with includeif onbranch","fromName":"Angelo Dureghello","fromEmail":"angelo@kernel-space.org","sentAt":"2024-03-08T20:27:22Z","receivedAt":"2024-03-08T20:28:01Z","isPatch":false,"sender":{"key":"angelo@kernel-space.org","avatar":null},"body":"Hi Brian,\n\nOn 08/03/24 9:10 PM, brian m. carlson wrote:\n> On 2024-03-08 at 19:25:52, Angelo Dureghello wrote:\n>> Hi,\n>>\n>> below the bug report, not totally sure this is a bug btw.\n>>\n>> ---\n>>\n>> Thank you for filling out a Git bug report!\n>> Please answer the following questions to help us understand your issue.\n>>\n>> What did you do before the bug happened? (Steps to reproduce your issue)\n>>\n>> Perform a git clone https with includeif onbranch in the .gitconfig\n>>\n>> Create a .gitconfig\n>> with\n>> [includeIf \"onbranch:wip/pippo/**\"]\n>>          path = ~/.gitconfig.pippo.inc\n>>\n>> git clone https://github.com/analogdevicesinc/no-OS.git\n>>\n>> Cloning into 'no-OS'...\n>> BUG: refs.c:2083: reference backend is unknown\n>> error: git-remote-https died of signal 6\n> \n> Thanks for the report.\n> \n> I can definitely confirm this with a local Git 2.44.0 built out of my\n> working tree.  It seems to trigger as long as there's a `path` entry\n> whether the path exists or not.  It _doesn't_ seem to trigger with a\n> `gitdir` check, but does trigger for `onbranch`.  v2.43.0 is not\n> affected.\n> \n> I do definitely think this is a bug.  First of all, we should not\n> trigger BUG conditions, even if the user has done something naughty, so\n> we should fix it for that reason.  Second of all, this seems like a\n> completely reasonable thing to want to do, and considering it triggers\n> for existing files, and that it worked just fine in v2.43.0, I don't see\n> a reason we shouldn't have this work.\n> \n> A bisection[0] leads us to 0fcc285c5e (\"refs: refactor logic to look up\n> storage backends\", 2023-12-29).  I've CCed the author of that commit,\n> who hopefully can provide some more helpful context.\n> \n> I have some guesses about what's going on here, but I haven't poked\n> further into the situation, so I'll refrain from speculating for now.\n> \n> [0] git bisect run sh -c 'make -j12 && cd $TMPDIR && rm -fr no-OS && PATH=\"$HOME/checkouts/git/bin-wrappers:$PATH\" git clone https://github.com/analogdevicesinc/no-OS.git; RET=$?; [ \"$RET\" -eq 128 ] && RET=1; exit $RET'\n\nThanks a lot.\n\nActually i can work with  git clone git@github.com:..   that works,\nissue is only on http.\n\nRegards, and if i can help, welcome.\nangelo\n\n\n\n"},{"id":"490271","messageId":"0a9601da719e$6cc85250$4658f6f0$@nexbridge.com","threadId":"61076","inReplyTo":"Zetw0I0NHgABR_PX@tapette.crustytoothpaste.net","subject":"RE: [BUG] cannot git clone with includeif onbranch","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-03-08T21:20:14Z","receivedAt":"2024-03-08T21:20:40Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Friday, March 8, 2024 3:11 PM, brian m. carlson wrote:\n>On 2024-03-08 at 19:25:52, Angelo Dureghello wrote:\n>> Hi,\n>>\n>> below the bug report, not totally sure this is a bug btw.\n>>\n>> ---\n>>\n>> Thank you for filling out a Git bug report!\n>> Please answer the following questions to help us understand your issue.\n>>\n>> What did you do before the bug happened? (Steps to reproduce your\n>> issue)\n>>\n>> Perform a git clone https with includeif onbranch in the .gitconfig\n>>\n>> Create a .gitconfig\n>> with\n>> [includeIf \"onbranch:wip/pippo/**\"]\n>>         path = ~/.gitconfig.pippo.inc\n>>\n>> git clone https://github.com/analogdevicesinc/no-OS.git\n>>\n>> Cloning into 'no-OS'...\n>> BUG: refs.c:2083: reference backend is unknown\n>> error: git-remote-https died of signal 6\n>\n>Thanks for the report.\n>\n>I can definitely confirm this with a local Git 2.44.0 built out of my working tree.  It seems to trigger as long as there's a `path` entry\n>whether the path exists or not.  It _doesn't_ seem to trigger with a `gitdir` check, but does trigger for `onbranch`.  v2.43.0 is not\n>affected.\n>\n>I do definitely think this is a bug.  First of all, we should not trigger BUG conditions, even if the user has done something naughty, so we\n>should fix it for that reason.  Second of all, this seems like a completely reasonable thing to want to do, and considering it triggers for\n>existing files, and that it worked just fine in v2.43.0, I don't see a reason we shouldn't have this work.\n>\n>A bisection[0] leads us to 0fcc285c5e (\"refs: refactor logic to look up storage backends\", 2023-12-29).  I've CCed the author of that\n>commit, who hopefully can provide some more helpful context.\n>\n>I have some guesses about what's going on here, but I haven't poked further into the situation, so I'll refrain from speculating for now.\n>\n>[0] git bisect run sh -c 'make -j12 && cd $TMPDIR && rm -fr no-OS && PATH=\"$HOME/checkouts/git/bin-wrappers:$PATH\" git clone\n>https://github.com/analogdevicesinc/no-OS.git; RET=$?; [ \"$RET\" -eq 128 ] && RET=1; exit $RET'\n\nI was wondering whether this should only work on a clone with -b wip/pippo/... argument, although it should not fail the clone, just not apply the path. I can see how it would be somewhat confusing if the global config defaults to master and remote only serves up main - or vise-versa.\n\n--Randall\n\n"},{"id":"490433","messageId":"Ze-UBgQtoWK8Rk4F@tanuki","threadId":"61076","inReplyTo":"Zetw0I0NHgABR_PX@tapette.crustytoothpaste.net","subject":"Re: [BUG] cannot git clone with includeif onbranch","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-11T23:30:14Z","receivedAt":"2024-03-11T23:30:23Z","isPatch":false,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Mar 08, 2024 at 08:10:56PM +0000, brian m. carlson wrote:\n> On 2024-03-08 at 19:25:52, Angelo Dureghello wrote:\n> > Hi,\n> > \n> > below the bug report, not totally sure this is a bug btw.\n> > \n> > ---\n> > \n> > Thank you for filling out a Git bug report!\n> > Please answer the following questions to help us understand your issue.\n> > \n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> > \n> > Perform a git clone https with includeif onbranch in the .gitconfig\n> > \n> > Create a .gitconfig\n> > with\n> > [includeIf \"onbranch:wip/pippo/**\"]\n> >         path = ~/.gitconfig.pippo.inc\n> > \n> > git clone https://github.com/analogdevicesinc/no-OS.git\n> > \n> > Cloning into 'no-OS'...\n> > BUG: refs.c:2083: reference backend is unknown\n> > error: git-remote-https died of signal 6\n> \n> Thanks for the report.\n> \n> I can definitely confirm this with a local Git 2.44.0 built out of my\n> working tree.  It seems to trigger as long as there's a `path` entry\n> whether the path exists or not.  It _doesn't_ seem to trigger with a\n> `gitdir` check, but does trigger for `onbranch`.  v2.43.0 is not\n> affected.\n> \n> I do definitely think this is a bug.  First of all, we should not\n> trigger BUG conditions, even if the user has done something naughty, so\n> we should fix it for that reason.  Second of all, this seems like a\n> completely reasonable thing to want to do, and considering it triggers\n> for existing files, and that it worked just fine in v2.43.0, I don't see\n> a reason we shouldn't have this work.\n> \n> A bisection[0] leads us to 0fcc285c5e (\"refs: refactor logic to look up\n> storage backends\", 2023-12-29).  I've CCed the author of that commit,\n> who hopefully can provide some more helpful context.\n> \n> I have some guesses about what's going on here, but I haven't poked\n> further into the situation, so I'll refrain from speculating for now.\n> \n> [0] git bisect run sh -c 'make -j12 && cd $TMPDIR && rm -fr no-OS && PATH=\"$HOME/checkouts/git/bin-wrappers:$PATH\" git clone https://github.com/analogdevicesinc/no-OS.git; RET=$?; [ \"$RET\" -eq 128 ] && RET=1; exit $RET'\n\nThanks for bisecting! My first hunch would've been that it's caused by\nthe change that changed when we initialize the refdb. I would have thus\nhoped for 199f44cb2e (builtin/clone: allow remote helpers to detect\nrepo, 2024-02-27) to have fixed the issue. But the bisected commit\npoints into a different direction, so I'd be surprised if that was it.\n\nAnyway, I didn't yet have the time to investigate this issue further,\nand am currently a bit short on time. I will have a deeper look next\nweek at the latest.\n\nPatrick\n"},{"id":"490480","messageId":"0bede59a53862585c49bc635f82e44e983144a7f.1710246859.git.ps@pks.im","threadId":"61076","inReplyTo":"72771da0-a0ef-4fd9-8071-6467cd7b6a6b@kernel-space.org","subject":"[PATCH] t5601: exercise clones with \"includeIf.*.onbranch\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-12T12:35:11Z","receivedAt":"2024-03-12T12:35:22Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"It was reported that git-clone(1) started to fail in Git v2.44 when\ncloning via HTTPS when the config contains an \"includeIf.*.onbranch\"\ncondition:\n\n    $ git clone https://example.com/repo.git\n    Cloning into 'repo'...\n    BUG: refs.c:2083: reference backend is unknown\n    error: git-remote-https died of signal 6\n\nThis regression was bisected to 0fcc285c5e (refs: refactor logic to look\nup storage backends, 2023-12-29). This commit tightens the logic to look\nup ref backends such that we now die when the backend has not yet been\ndetected by reading the gitconfig.\n\nNow on its own, this commit wouldn't have caused the failure. But in\n18c9cb7524 (builtin/clone: create the refdb with the correct object\nformat, 2023-12-12) we have also changed how git-clone(1) initializes\nthe refdb such that it happens after the remote helper is spawned, which\nis required so that we can first learn about the object format used by\nthe remote repository before initializing the refdb. Starting with this\nchange, the remote helper will be unable to detect the repository right\nfrom the start and thus have an unconfigured ref backend. Consequently,\nwhen we try to resolve the \"includeIf.*.onbranch\" condition, we will now\nfail to look up the refdb and die.\n\nThis regression has already been fixed via 199f44cb2e (builtin/clone:\nallow remote helpers to detect repo, 2024-02-27), where we now\npre-initialize a partial refdb so that the remote helper can detect the\nrepository right from the start. But it's clear that we're lacking test\ncoverage of this functionality.\n\nAdd a test to avoid regressing in the future. Note that this test stops\nshort of defining the desired behaviour for the \"onbranch\" condition\nduring a clone. It's not quite clear how exactly it should behave, so\nthis is a leftover bit for the future.\n\nReported-by: Angelo Dureghello <angelo@kernel-space.org>\nSigned-off-by: Patrick Steinhardt <ps@pks.im>\n---\n t/t5601-clone.sh | 12 ++++++++++++\n 1 file changed, 12 insertions(+)\n\ndiff --git a/t/t5601-clone.sh b/t/t5601-clone.sh\nindex fb1b9c686d..ca43185681 100755\n--- a/t/t5601-clone.sh\n+++ b/t/t5601-clone.sh\n@@ -776,6 +776,18 @@ test_expect_success 'batch missing blob request does not inadvertently try to fe\n . \"$TEST_DIRECTORY\"/lib-httpd.sh\n start_httpd\n \n+test_expect_success 'clone with includeIf' '\n+\ttest_when_finished \"rm -rf repo \\\"$HTTPD_DOCUMENT_ROOT_PATH/repo.git\\\"\" &&\n+\tgit clone --bare --no-local src \"$HTTPD_DOCUMENT_ROOT_PATH/repo.git\" &&\n+\n+\ttest_when_finished \"rm \\\"$HOME\\\"/.gitconfig\" &&\n+\tcat >\"$HOME\"/.gitconfig <<-EOF &&\n+\t[includeIf \"onbranch:something\"]\n+\t\tpath = /does/not/exist.inc\n+\tEOF\n+\tgit clone $HTTPD_URL/smart/repo.git repo\n+'\n+\n test_expect_success 'partial clone using HTTP' '\n \tpartial_clone \"$HTTPD_DOCUMENT_ROOT_PATH/server\" \"$HTTPD_URL/smart/server\"\n '\n-- \n2.44.0\n\n"},{"id":"490502","messageId":"xmqqo7bjjid9.fsf@gitster.g","threadId":"61076","inReplyTo":"0bede59a53862585c49bc635f82e44e983144a7f.1710246859.git.ps@pks.im","subject":"Re: [PATCH] t5601: exercise clones with \"includeIf.*.onbranch\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-12T20:38:26Z","receivedAt":"2024-03-12T20:38:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> +test_expect_success 'clone with includeIf' '\n> +\ttest_when_finished \"rm -rf repo \\\"$HTTPD_DOCUMENT_ROOT_PATH/repo.git\\\"\" &&\n> +\tgit clone --bare --no-local src \"$HTTPD_DOCUMENT_ROOT_PATH/repo.git\" &&\n> +\n> +\ttest_when_finished \"rm \\\"$HOME\\\"/.gitconfig\" &&\n> +\tcat >\"$HOME\"/.gitconfig <<-EOF &&\n> +\t[includeIf \"onbranch:something\"]\n> +\t\tpath = /does/not/exist.inc\n> +\tEOF\n> +\tgit clone $HTTPD_URL/smart/repo.git repo\n> +'\n\nHmph, isn't the end-user expectation more like if you clone with\n\"git clone -b something\" then the configuration stored in the named\nfile to take effect, while \"git clone\" that would never place you on\nthat something branch would ignore that missing file?  Is this only\nthe latter half of the pair?\n\nThanks.\n"},{"id":"491203","messageId":"ZfzmdcBT5MUqoxrk@tanuki","threadId":"61076","inReplyTo":"xmqqo7bjjid9.fsf@gitster.g","subject":"Re: [PATCH] t5601: exercise clones with \"includeIf.*.onbranch\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-22T02:01:25Z","receivedAt":"2024-03-22T02:01:31Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Mar 12, 2024 at 01:38:26PM -0700, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > +test_expect_success 'clone with includeIf' '\n> > +\ttest_when_finished \"rm -rf repo \\\"$HTTPD_DOCUMENT_ROOT_PATH/repo.git\\\"\" &&\n> > +\tgit clone --bare --no-local src \"$HTTPD_DOCUMENT_ROOT_PATH/repo.git\" &&\n> > +\n> > +\ttest_when_finished \"rm \\\"$HOME\\\"/.gitconfig\" &&\n> > +\tcat >\"$HOME\"/.gitconfig <<-EOF &&\n> > +\t[includeIf \"onbranch:something\"]\n> > +\t\tpath = /does/not/exist.inc\n> > +\tEOF\n> > +\tgit clone $HTTPD_URL/smart/repo.git repo\n> > +'\n> \n> Hmph, isn't the end-user expectation more like if you clone with\n> \"git clone -b something\" then the configuration stored in the named\n> file to take effect, while \"git clone\" that would never place you on\n> that something branch would ignore that missing file?  Is this only\n> the latter half of the pair?\n\nIt probably is, but I'm not really sure to be honest. That's why I\npunted on it and just assert that it doesn't die.\n\nIn any case I would claim that the current behaviour is really quite\nbroken in Git v2.43:\n\n```\n$ cat >$HOME/.gitconfig <<EOF\n[includeIf \"onbranch:master\"]\n    path = $HOME/include\nEOF\n\n$ cat >$HOME/include <<EOF\ngarbage\nEOF\n\n# Init source with a different branch name than our condition.\n$ git init source --initial-branch=main\n$ git -C source commit --allow-empty -m initial\n\n$ git clone source target\nCloning into 'target'...\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nremote: Enumerating objects: 2, done.\nremote: Counting objects: 100% (2/2), done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0\nReceiving objects: 100% (2/2), done.\nerror: key does not contain a section: garbage\n\n$ git clone -b main source target\nCloning into 'target'...\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nremote: Enumerating objects: 2, done.\nremote: Counting objects: 100% (2/2), done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0\nReceiving objects: 100% (2/2), done.\nerror: key does not contain a section: garbage\n\n$ git clone -b other source target\nCloning into 'target'...\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nerror: key does not contain a section: garbage\nremote: Enumerating objects: 2, done.\nremote: Counting objects: 100% (2/2), done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0\nReceiving objects: 100% (2/2), done.\nerror: key does not contain a section: garbage\n\n$ cat >$HOME/.gitconfig <<EOF\n[includeIf \"onbranch:other\"]\n    path = $HOME/include\nEOF\n$ git -C source branch other\n\n$ git clone -b other source target\nCloning into 'target'...\nremote: Enumerating objects: 2, done.\nremote: Counting objects: 100% (2/2), done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0\nReceiving objects: 100% (2/2), done.\nerror: key does not contain a section: garbage\n```\n\nSo the behaviour is inconsistent already and does not make a lot of\nsense. Part of the problem is likely that we pre-initialize \"HEAD\" to\n\"refs/heads/master\", which is why you can see some of the includes being\ntriggered.\n\nWith Git v2.44 this behaviour did indeed change, and arguably for the\nbetter. This is because we now pre-init \"HEAD\" to \"refs/heads/.invalid\"\ninstead of using the default branch name. Thus, we do not match \"master\"\nanymore, which is likely the correct thing to do.\n\n```\n$ cat >$HOME/.gitconfig <<EOF\n[includeIf \"onbranch:other\"]\n    path = $HOME/include\nEOF\n\n$ git clone -b main source target\nCloning into 'target'...\nremote: Enumerating objects: 2, done.\nremote: Counting objects: 100% (2/2), done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (2/2), done.\n\n$ git clone -b other source target\nCloning into 'target'...\nremote: Enumerating objects: 2, done.\nremote: Counting objects: 100% (2/2), done.\nremote: Total 2 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)\nReceiving objects: 100% (2/2), done.\nerror: key does not contain a section: garbage\n```\n\nSo arguably, the \".invalid\" hack actually fixed this case somewhat and\nmade it behave saner. But I'm just not sure whether I feel comfortable\nenough with all of this incidental behaviour to actually put it into a\ntest and cast it into stone.\n\nThus the current version of my test that simply asserts that this does\nsomething successfully instead of crashing. In my opinion, we need to\nput more thought into how this is supposed to work before adding more\ntests.\n\nPatrick\n"},{"id":"491206","messageId":"xmqq34sj583m.fsf@gitster.g","threadId":"61076","inReplyTo":"ZfzmdcBT5MUqoxrk@tanuki","subject":"Re: [PATCH] t5601: exercise clones with \"includeIf.*.onbranch\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-22T02:11:09Z","receivedAt":"2024-03-22T02:11:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> With Git v2.44 this behaviour did indeed change, and arguably for the\n> better. This is because we now pre-init \"HEAD\" to \"refs/heads/.invalid\"\n> instead of using the default branch name. Thus, we do not match \"master\"\n> anymore, which is likely the correct thing to do.\n\n;-)\n\n> Thus the current version of my test that simply asserts that this does\n> something successfully instead of crashing. In my opinion, we need to\n> put more thought into how this is supposed to work before adding more\n> tests.\n\nOK.  That is a sensible position to take.\n\nThanks.\n\n"},{"id":"491208","messageId":"Zfzp0cxe68My35gW@tanuki","threadId":"61076","inReplyTo":"ZfzmdcBT5MUqoxrk@tanuki","subject":"Re: [PATCH] t5601: exercise clones with \"includeIf.*.onbranch\"","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2024-03-22T02:15:45Z","receivedAt":"2024-03-22T02:15:51Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Fri, Mar 22, 2024 at 03:01:25AM +0100, Patrick Steinhardt wrote:\n> On Tue, Mar 12, 2024 at 01:38:26PM -0700, Junio C Hamano wrote:\n> > Patrick Steinhardt <ps@pks.im> writes:\n[snip]\n> With Git v2.44 this behaviour did indeed change, and arguably for the\n> better. This is because we now pre-init \"HEAD\" to \"refs/heads/.invalid\"\n> instead of using the default branch name. Thus, we do not match \"master\"\n> anymore, which is likely the correct thing to do.\n\nThis is wrong by the way. I didn't mean to say Git v2.44, but the\nupcoming Git v2.45 starting with 199f44cb2e (builtin/clone: allow remote\nhelpers to detect repo, 2024-02-27).\n\nPatrick\n"}]}