Cannot use submodule commit whose commitid resolves to HEAD on a Github Pull Request on Flatpak 0.10 & Git <2.14 #1133
Comments
|
For a real, pony-free example, try https://github.com/mono/monodevelop tag monodevelop-7.2.0.636: https://jenkins.mono-project.com/view/Releases/job/release-flatpak-monodevelop/198/console |
alexlarsson
added a commit
to flatpak/flatpak-builder
that referenced
this issue
Oct 27, 2017
It turns out older versions of git cannot properly check out a commit if the ref that points to it was not a normal one (branch or tag). So, we work around this case by detecting it add adding a fake tag. Also, we change the fake ref we use for commit-only references to be a regular branch and not a special one for the same reason. This fixes flatpak/flatpak#1133
|
For the record, we pull the tip of a pull request branch because there is no other way to pull a specific commit. If you pull a commit id directly you get a denied error from the server. If we can't find it at the tip of some ref, then we fall back to a deep clone. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm not positive about which commit in git resolves the issue (that's a huge pain in the ass to bisect), but there's a combination of factors which leads to pain. For an easy example, try building https://github.com/directhex/pony-flatpak. The "good" behaviour is the build fails. The "bad" behaviour is the checkout fails.
On Flatpak 0.10, one new feature is to speed up builds, shallow clones are used. Part of this is submodule commitids are resolved to branches. For whatever reason, if a submodule points to a commit which is available as the tip of a pull request branch, then the fetch resolves to the pull request branch instead of the master branch (or any other branch containing that commit):
On git 2.14.1, this works fine:
On git 2.7.4, it fails the build:
Since PR refs are special-cased in the Github back-end, maybe Flatpak should be taught to avoid them? Or include a git version check on shallow cloning?
The text was updated successfully, but these errors were encountered: