### What needs to get done The `source-commit` tag should be included in `manifest.yaml` for `source-type: git` parts where `snapcraft.yaml` only specified tags/branches (or no tag/branch at all). At the moment, it is the responsibility of the packager to ensure that the version specified in `snapcraft.yaml` can be tracked back to a commit; while this may be reasonably expected for most software deployed in production, it's [not guaranteed](https://github.com/canonical/microceph/blob/84b63149e55b801f77ef1237f9af91c97b5e5ebc/snap/snapcraft.yaml#L283). Since the source commit hash for the part is (presumably) known by snapcraft at build time, it should be inserted into the manifest. Additionally, that commit hash should be included in the build log. ### Why it needs to get done For snap build `part`s with `source-type: git` that don't specify a revision, the `manifest.yaml` included in the snap artifact does not include the git revision that was checked out as part of the build. As a snap user/administrator/support engineer, I need the ability to find the exact revision of source code that's included in a deployed snap. For example, MicroCeph's `manifest.yaml` does not include a git revision for the dqlite and raft shared libraries ([`snapcraft.yaml`](https://github.com/canonical/microceph/blob/84b63149e55b801f77ef1237f9af91c97b5e5ebc/snap/snapcraft.yaml#L283)). It is currently impossible to know based on the snap revision which version of dqlite is being used in customer environments. We are engaging with MicroCeph separately to improve that specific case.