Crashpad submodule reference doesn't point to a valid commit

[csk-ableton]

Description

The Crashpad submodule reference doesn't point to a commit on a branch (should be getsentry I guess), see the error when visiting https://github.com/getsentry/crashpad/tree/f4c7710dc178218e1e58d9e0b65be91cc5dbd66c. I'm not sure how this commit is kept alive and I'm not able to checkout the commit. It is however possible to initialize the submodule fine from within this repository (I'm not clear why).

I have a more complex integration of the library and manually checkout https://github.com/getsentry/crashpad which is currently not possible.

When does the problem happen

• [x] During build
• [ ] During run-time
• [ ] When capturing a hard crash

Environment

• OS: macOS

Steps To Reproduce

git clone https://github.com/getsentry/crashpad
cd crashpad
git checkout f4c7710dc178218e1e58d9e0b65be91cc5dbd66c

Log output

fatal: reference is not a tree: f4c7710dc178218e1e58d9e0b65be91cc5dbd66c

[supervacuus]

Hi @csk-ableton, thanks for the report.

The Crashpad submodule reference doesn't point to a commit on a branch (should be getsentry, I guess)

This is a minor oversight because I often create PRs on both sides, where I reference a commit (from the sentry-native PR) in the PR of the submodule repository (in this case, getsentry/crashpad). This allows me to test the changes made in the submodule in the context of the Native SDK before I merge the PR in the submodule.

I squashed the PR's commits this time when merging it, leaving the submodule-referenced commit orphaned. I will explain why this is not overly critical below (I will fix the reference nonetheless, but won't create a separate release for it).

I'm not sure how this commit is kept alive

Any commit ends up in the repos object database, where it will stay forever. At some point, an orphan commit (disconnected from either branch or tag) could be garbage collected (see git docs).

However, in this case, the commit is part of a PR, and GitHub stores the commit in the target-repo's object database even before the PR is merged. This allows us to reference commits from PRs in submodules in the first place (even though they are not yet part of any branch in the target repo). As far as I know, commits from a PR will never get automatically garbage collected from GitHub, which is why you can see all commits made in any PR on GitHub long after they've been merged.

It is however possible to initialize the submodule fine from within this repository (I'm not clear why)

This is possible because the submodule fetches that particular commit, which will stay in the submodule repository indefinitely if it is part of a PR.

I'm not able to checkout the commit

You're getting fatal: reference is not a tree because you clone the repo and get the default branch getsentry, which is unrelated to the commit. If you run

git fetch origin f4c7710dc178218e1e58d9e0b65be91cc5dbd66c

it will happily add it to the local object database, and you can check it out.

By the way, the contents of the last commit, 96e301b7d6b81990a244d7de41a0d36eeb60899e, in the getsentry branch and the referenced submodule commit are the same even if they do not have the same object SHA.

[csk-ableton]

Hi @supervacuus, thanks for the fast and detailed reply! I didn't realize the orphaned commit isn't fetched automatically and I have to do it explicitly (and that's what the submodule init is doing). That makes all sense then.

[supervacuus]

Fixed in #1000.