brew.sh: fix handling of dirty git repo

[carlocab]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

We cache the output of git describe, but we don't check whether the
cached value is valid.

This fixes that.

[Bo98]

Can you performance bench before and after this change?

[carlocab]

Tiny bit slower, but not much:

❯ hyperfine --parameter-list branch master,version-cache-handling --warmup 5 --setup 'git switch {branch}' 'brew config'
Benchmark 1: brew config (branch = master)
  Time (mean ± σ):     428.1 ms ±   1.7 ms    [User: 146.5 ms, System: 117.9 ms]
  Range (min … max):   425.9 ms … 431.9 ms    10 runs

Benchmark 2: brew config (branch = version-cache-handling)
  Time (mean ± σ):     435.0 ms ±   1.7 ms    [User: 146.8 ms, System: 117.1 ms]
  Range (min … max):   433.3 ms … 438.7 ms    10 runs

Summary
  brew config (branch = master) ran
    1.02 ± 0.01 times faster than brew config (branch = version-cache-handling)

❯ hyperfine --parameter-list branch master,version-cache-handling --warmup 5 --setup 'git switch {branch}' 'brew --version'
Benchmark 1: brew --version (branch = master)
  Time (mean ± σ):      84.1 ms ±   0.7 ms    [User: 21.1 ms, System: 25.0 ms]
  Range (min … max):    82.8 ms …  85.3 ms    35 runs

Benchmark 2: brew --version (branch = version-cache-handling)
  Time (mean ± σ):      92.8 ms ±   1.2 ms    [User: 23.5 ms, System: 38.4 ms]
  Range (min … max):    91.6 ms …  96.8 ms    31 runs

Summary
  brew --version (branch = master) ran
    1.10 ± 0.02 times faster than brew --version (branch = version-cache-handling)

Worst-case delay is 14ms (max of brew --version after this change minus min of brew --version before this change) which is just on the edge of imperceptible. Average delay is about 8ms, which most people can't perceive.

[carlocab]

I can shave about a millisecond off this by using read instead of cat.

[carlocab]

Using read instead of cat:

❯ hyperfine --parameter-list branch master,version-cache-handling --warmup 5 --setup 'git switch {branch}' 'brew config'
Benchmark 1: brew config (branch = master)
  Time (mean ± σ):     430.7 ms ±   3.9 ms    [User: 147.3 ms, System: 119.4 ms]
  Range (min … max):   426.6 ms … 439.9 ms    10 runs

Benchmark 2: brew config (branch = version-cache-handling)
  Time (mean ± σ):     438.3 ms ±   4.0 ms    [User: 147.9 ms, System: 119.0 ms]
  Range (min … max):   434.4 ms … 445.0 ms    10 runs

Summary
  brew config (branch = master) ran
    1.02 ± 0.01 times faster than brew config (branch = version-cache-handling)

❯ hyperfine --parameter-list branch master,version-cache-handling --warmup 5 --setup 'git switch {branch}' 'brew --version'
Benchmark 1: brew --version (branch = master)
  Time (mean ± σ):      85.1 ms ±   1.2 ms    [User: 21.2 ms, System: 25.7 ms]
  Range (min … max):    82.9 ms …  88.8 ms    34 runs

Benchmark 2: brew --version (branch = version-cache-handling)
  Time (mean ± σ):      91.8 ms ±   0.3 ms    [User: 23.4 ms, System: 37.9 ms]
  Range (min … max):    91.1 ms …  92.5 ms    31 runs

Summary
  brew --version (branch = master) ran
    1.08 ± 0.02 times faster than brew --version (branch = version-cache-handling

[Bo98]

OK seems worth it for correctness

[Bo98]

Note that git diff-index can produce incorrect results without a git update-index --refresh. For example if someone edits a file and then reverts those changes (simplest reproducer: touch "$(brew --repo)/Dockerfile").

May be worth comparing speed and correctness to checking if git status --porcelain --untracked-files=no is non-empty (or adding git update-index --refresh but I suspect two commands may be slower)

[MikeMcQuaid]

Looks good! Would like to see reordering but using git diff is optional if it's slower.

[MikeMcQuaid]

Thanks @carlocab!