Open mgorny opened 4 days ago
I wonder if we should pin git
to <2.46 to avoid this error altogether? Or maybe in the gitpython
recipe.
Edit: Nah, that'd be too late if the repo has been cloned already. We might need to catch the exception and print some informative error instead, because the user might need to re-clone.
Edit 2: Maybe we can use git update-index --index-version 2
programmatically?
We also probably need to start thinking of a long-term solution, which probably involves replacing GitPython.
Dulwich looks well maintained, nice API, no git
dependency! There's also pygit2
but Dulwich seems more popular (see below). Both are available on conda-forge already.
An argument in favor of pygit2
would be that it's based on libgit2
which is also used by Rust/Cargo.
No strong opinions. Note that conda-forge/conda-forge-webservices
and conda-forge/admin-migrations
seem to also depend on gitpython
, in case they need updates too.
Solution to issue cannot be found in the documentation.
Issue
When using new enough git (2.47.0 here), all newly cloned repositories are using index version 3. When trying to use conda-smithy on such a repository, I'm getting the following error:
This seems to be https://github.com/gitpython-developers/GitPython/issues/1960. However, from what I understand it's unlikely to be fixed anytime soon, so perhaps some solution on conda-smithy end would be preferable.
A possible workaround is to force
feature.manyFiles=false
in git while cloning the repository.Installed packages
Environment info