record Git revision in devel builds

[geekosaur]

cabal --version in such builds will include the Git commit and branch (if not master).

I've already been informed that this is not appropriate, but maybe someone will find something worth salvaging in it. It is also incomplete insofar as it needs a changelog entry and such (but probably not a test).

Consider this my last submission.

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[geekosaur]

hilfy «cabal:git-revs@39b5fae1a$» Z$ $(cabal list-bin cabal) --version
cabal-install version 3.15.0.0 (commit 39b5fae on git-revs, Sun Nov 10 03:13:17 2024 -0500)
compiled using version 3.15.0.0 of the Cabal library (in-tree)

I did come up with a reasonable situation where Cabal could have different git information than cabal-install, so I added that back in. (Building a pre-release cabal-install package with a pre-release ghc, not in-tree, such that ghc's libraries/cabal is used.) I did simplify the output if it's the same, as shown above.

[ulysses4ever]

Hey @geekosaur! Do you have any plans around this one? It'd be great to have the SHA one way or another...

[geekosaur]

Also, someone checked "significant" in the checklist. The thing is, this only changes behavior for development builds; it won't be in release builds, because we can't use TH in those (consider that there's a Debian maintainer making unregisterised ghc builds for s390x and ppc64le among others), so I'm not sure it needs to be in release notes at all.

[ulysses4ever]

I don't think we need separate git info machinery for the library and the tool since they live in the same repository. Maybe some corner cases could benefit from it but I doubt they appear in practice often enough to justify the sensitive cost of CPP (and code duplication between cabalGitInfo and cabalInstallGitInfo). I also don't see much value in the (in tree) label: I'd be happier with a binary choice --- SHA or no SHA depending on the flag --- if this saves on the duplication and the CPP.

I'd also try to avoid adding any more CPP at all costs. The usual hack with two modules conditionally employed in the cabal file based on the flag would be my preferred way.

But as discussed elsewhere, we really need this feature ASAP, so I don't want to hold this any longer.

[Mikolaj]

LGTM

[Mikolaj]

@mergify backport 3.14

[mergify]

backport 3.14

✅ Backports have been created

Details

• #10864 Backport #10541: record Git revision in devel builds has been created for branch 3.14 but encountered conflicts

[Mikolaj]

There are conflicts and this is not an urgent fix, so I propose to skip the 3.14 backport.