We're using essentially the same logic to setup Git for committing in
multiple places but the way we're doing so is inconsistent. Moved to
using two shared utility methods and use them consistently.
- My refactoring of #7933 went wrong in that the tests passed for `brew
extract` and my manual testing, but both forgot about third-party taps
exist, so that functionality broke as follows (courtesy of Misty).
Before:
```
# Git.last_revision_commit_of_files("/usr/local/Homebrew", ["LICENSE.txt", "README.md"])
=> ["ac0665d", ["README.md"]]
```
After:
```
# Git.last_revision_commit_of_files("/usr/local/Homebrew", ["LICENSE.txt", "README.md"])
=> [nil, []]
```
- While we think about how to do splats in Sorbet, revert this so
that users are able to `brew extract` from third party taps again.
- A TODO for later in a separate PR is to write a test for `brew
extract` that tests the behaviour of third-party taps.
---
- Reverted this manually because the GitHub UI couldn't do it.
- Arguably I didn't need to remove the RBI file, but it's easier to have
everything gone for now and then revert this revert in future once we
have a strategy for dealing with splats in Sorbet than have
inconsistency.
Format for oneline can be overridden in user's gitconfig. If that's the
case, last_revision_commit_of_file won't work properly, and because of
that last_revision_of_file won't work at all.
Here's what I was getting when running brew tests:
expected: "6bec2de"
got: "\e[33m6bec2dee633f\e[m"
I have abbrev length set to 12, and oneline formatting is more colorful.
So, instead of relying on overrideable format, it should rather specify
"--format=%h" to get only hash, and speciy --abbrev=7 to force abbrev
length to be 7
After this commit tests are passing for me.
Git is a transport and storage mechanism for us so we don't want to
allow arbitrary customisation of this due to user issues e.g. #3664
and #3561.
Fixes#3664.
