version: retrieve commit hash for git worktrees

[SnoopJ]

Description

Tin and personal wish fulfillment. With this changeset, the version command will report commit information if Sopel is running from a git-worktree.

The current revision of the version plugin only supports reading commit information when the host Sopel is running inside of a 'real' git repository. I find it convenient to run Sopel from a worktree for a "near to development" copy, and it's nice to still have the commit information in this use-case.

Checklist

• I have read CONTRIBUTING.md
• I can and do license this contribution under the EFLv2
• No issues are reported by make qa (runs make lint and make test)
  • I did see some errors when running mypy because types-urllib3 was not installed. I'm not sure if that's missing from dev-requirements.txt or if my local environment was in a weird state.
  • Also saw some test failures in test_example_suggest_* caused by content decoding errors. I only vaguely recognize the issue, but I'm confident it's not this changeset's fault.
• I have tested the functionality of the things this change touches

[dgw]

• I did see some errors when running mypy because types-urllib3 was not installed. I'm not sure if that's missing from dev-requirements.txt or if my local environment was in a weird state.

Well it's not in dev-requirements.txt, and CI doesn't appear to install it from anywhere, but in CI its absence doesn't cause any make lint errors. Curious. Locally, pipdeptree doesn't even identify any packages as depending on types-urllib3 either, yet it's present in my environment. Let's chase this one down if it happens to anyone else.

• Also saw some test failures in test_example_suggest_* caused by content decoding errors. I only vaguely recognize the issue, but I'm confident it's not this changeset's fault.

It's the same issue I described in a couple of my PRs, and is probably because you haven't reinstalled/--upgraded the dev-requirements.txt since #2519 (if I had to guess).

To me, this change is low-stakes and could be shipped in 8.0.0 while I still lack the time (😩) to work on release notes. (It's just nuts how much stuff has kept coming up for me this month! I thought I had everything planned out for $work etc. but noooo.)

[SnoopJ]

It's the same issue I described in a couple of my PRs, and is probably because you haven't reinstalled/--upgraded the dev-requirements.txt since #2519 (if I had to guess).

Huh, I had an old urllib3. Might be why I saw types-urllib3 weirdness too. I could have sworn I installed the requirements file, but I guess I only manually installed the stubs. Maybe I left my environment in a bad state while checking something against 7.1.9.

To me, this change is low-stakes and could be shipped in 8.0.0 while I still lack the time (😩) to work on release notes. (It's just nuts how much stuff has kept coming up for me this month! I thought I had everything planned out for $work etc. but noooo.)

Maybe, but let's defer it anyway IMO.

[Exirel]

That's looking good, feature wise. Code wise, it's mostly style related.

I didn't put a comment on the f variable, because it isn't important, however I tend to use fd (for file descriptor) instead of just f. In general, I prefer more expressive code and names. I don't think reducing the character count on variable names that are less than 10 characters matters.

[Exirel]

I don't feel comfortable having this in 8.0.1. I'm sure this can wait Sopel 8.1 - beside, it should be useful mostly when working with an unstable version from git, so something that would fit nicely in master and unreleased for now.

[SnoopJ]

I'm sure this can wait Sopel 8.1

Agreed

[Exirel]

A good squash would make the history more readable, other than that it's good to go!

[SnoopJ]

I'm impressed that there are no merge conflicts considering the age of this PR! Squashed down to 2 commits, I figure it makes sense to retain a separate commit for renaming the existing function.