Seeing "BUG: refs.c:2083: reference backend is unknown" when attempting to clone #4843
Closed
1 task done
Milestone
Comments
|
It should be noted that this works with the |
|
This is definitely not limited to Git for Windows. I am seeing the exact same thing on Manjaro: @dscho Clearly someone created an issue in version 2.44.0 of Git and it also appears in Git for Windows. NB: cloning with SSH works. And repo seems to be irrelevant, as long as HTTPS is used: |
|
@assarbad would you be so kind as to provide a backport PR? |
Will do (same person, company account) |
dscho
added a commit
that referenced
this issue
Apr 12, 2024
In 18c9cb7 (builtin/clone: create the refdb with the correct object format, 2023-12-12), we have changed git-clone(1) so that it delays creation of the refdb until after it has learned about the remote's object format. This change was required for the reftable backend, which encodes the object format into the tables. So if we pre-initialized the refdb with the default object format, but the remote uses a different object format than that, then the resulting tables would have encoded the wrong object format. This change unfortunately breaks remote helpers which try to access the repository that is about to be created. Because the refdb has not yet been initialized at the point where we spawn the remote helper, we also don't yet have "HEAD" or "refs/". Consequently, any Git commands ran by the remote helper which try to access the repository would fail because it cannot be discovered. This is essentially a chicken-and-egg problem: we cannot initialize the refdb because we don't know about the object format. But we cannot learn about the object format because the remote helper may be unable to access the partially-initialized repository. Ideally, we would address this issue via capabilities. But the remote helper protocol is not structured in a way that guarantees that the capability announcement happens before the remote helper tries to access the repository. Instead, fix this issue by partially initializing the refdb up to the point where it becomes discoverable by Git commands. ----- Cherry-picked the commit 199f44c to provide the backport-PR requested by @dscho in #4843 ... Commit message unchanged with the exception of the `Signed-off-by:`. The contents of the commit are anyway unchanged. Hope this works for you.
|
/add relnote bug A regression where The workflow run was started |
github-actions bot
pushed a commit
to git-for-windows/build-extra
that referenced
this issue
Apr 12, 2024
A [regression](git-for-windows/git#4843) where `git clone` no longer worked in the presence of `includeIf.*.onbranch` config settings [has been fixed](git-for-windows/git@199f44c). Signed-off-by: gitforwindowshelper[bot] <gitforwindowshelper-bot@users.noreply.github.com>
dscho
added a commit
to microsoft/git
that referenced
this issue
Apr 16, 2024
This is a backport of git-for-windows#4908 to address git-for-windows#4843 where cloning no longer worked if the user has configured any `includeIf.*.onbranch` settings in their gitconfig.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Setup
defaults?
to the issue you're seeing?
None that I am aware of
Details
Bash within Windows Terminal
Minimal, Complete, and Verifiable example
this will help us understand the issue.
I expected the clone to commence and succeed (the directory
test_helperexisted!).It aborted with the message:
URL to that repository to help us with testing?
https://github.com/bats-core/bats-core.git
The text was updated successfully, but these errors were encountered: