conan-io
[question] Intended requirement for Git 2.36 in Conan 2.17?
What is your question?
We discovered that Conan 2.17 now uses --refetch when checking if a commit is in the remote. Was this intended? Because this creates a hard dependency to Git >=2.36 which broke some of our older pipelines. Maybe it would be possible to fall back to another detection method in case --refetch is not supported.
The problem we're currently facing is with tag commits that are not on any branch. The first check branch -r --contains {commit} fails for obvious reasons. The second check fetch {remote} --refetch --dry-run {commit} works for the orphan tag commit but only on Git >=2.36. I'm also not really sure whether the code was designed for this corner case at all. Is there any other way to verify that orphan tag commits are in the remote (that works on a wide range of Git versions)?
Have you read the CONTRIBUTING guide?
- [x] I've read the CONTRIBUTING guide
Hi @jasal82
Thanks for your question.
Yes, when this fix was introduced (to solve grafted commits that happens in CI systems), we thought that https://github.com/git/git/releases/tag/v2.36.0 from April 2022 would be old enough, and systems running the very latest Conan would be using a more modern git too.
It might be possible to fallback to the previous mode in https://github.com/conan-io/conan/commit/42c5c36383f0005db6e16614ddfe6fd1d9a26829, with:
self.run("fetch {} --dry-run --depth=1 {}".format(remote, commit))
I think I'd prefer not to have to check the git version, that version check itself is another vector of other possible failures and bugs.
@memsharded I think it would be good to maximize Git version compatibility. The Git versions we're using are usually provided by the Docker images whereas Conan is installed (and updated) by the pipeline within the running containers. So the update cycles of these tools are decoupled and it's not always easy to just update Git in the image because of other dependencies (glibc version of the distro, etc).
Is the 'old' method functionally equivalent to the --refetch one? Because I understood that --refetch solves problems with negotiation between local and remote repositories.
Is the 'old' method functionally equivalent to the --refetch one? Because I understood that --refetch solves problems with negotiation between local and remote repositories.
Not really, the old functionality will not work for grafted commits, but I guess that would be better than just failing because --refetch is not supported. Can you please share the stacktrace or error messages that you are getting from the older git?
error: unknown option `refetch'
usage: git fetch [<options>] [<repository> [<refspec>...]]
or: git fetch [<options>] <group>
or: git fetch --multiple [<options>] [(<repository> | <group>)...]
or: git fetch --all [<options>]
[...]
Maybe it would be possible to distinguish between grafted commits (due to shallow clone) and tag-only commits (that do not live on a branch) and use two different methods? Just an idea.
I'll note that the standard Ubuntu 22 repos have Git 2.34. It's not the oldest of distros. I know that you can get a more recent version on there, but it is better to be able to work out of the box.
Unrelated, but just in case: https://github.blog/open-source/git/securing-git-addressing-5-new-vulnerabilities/ It is likely that at least git>=2.45.1 would be recommended to avoid a series of relatively high severity vulnerabilities
I am proposing https://github.com/conan-io/conan/pull/18501, to fallback to the older way not using -refetch, for cases like this git<2.36, for next Conan 2.17.1
https://github.com/conan-io/conan/pull/18501 closes this ticket, to be released in next Conan 2.17.1 soon. Thanks for your feedback.