- For a situation where `authored = 3`, `committed = 4`, the previous
calculation was `3 - 4` which meant that `committed = -1` in the end.
- This was incorrect, since a user can't have negative contributions!
- Instead, only do the subtraction to get the deduplicated `committed`
count if the number of authored commits is higher than the number of
committed commits. This approach should achieve the desired "don't
double count things that the user authored and committed, but do count
things that another person authored that the user committed".
- We want to move away from `Excludes:` in the main `.rubocop.yml` config file
containing full file paths, because it's hard to track whether they're still
necessary or not (and other occurrences in the files that you might
legitimately want to improve are unaccounted for).
This updates `ElectronBuilder` to use `Yaml#find_versions`, as the
only code unique to that strategy is to restrict regex usage and
use default version-finding logic when a `strategy` block isn't
provided. This is similar to how we have various strategies that
use `PageMatch#find_versions` internally.
This allows us to remove `ElectronBuilder#versions_from_content`
entirely, along with the related tests. I've added support for
`provided_content` to `ElectronBuilder#find_versions` as a way of
adding tests and maintaining code coverage.
This adds a generic `Yaml` strategy to livecheck that requires a
`strategy` block to operate. The YAML-parsing code is taken from the
existing approach in the `ElectronBuilder` strategy.
We don't currently have any `strategy` blocks in first-party taps
that manually parse YAML. However, creating a generic `Yaml` strategy
allows us to simplify `ElectronBuilder` (and any future strategy
that works with YAML) while making it easy to create custom `Yaml`
`strategy` blocks in formulae/casks as needed.
- Double counting is artificially inflating folks' contributions (sadly ;-)).
- Since I'm not going to enumerate every possible author to filter by *both*
fields via the API, let's do some arithmetic to figure out the unique
committer numbers for a user.
We set `core.fsmonitor` to `false` in #13586 because Git's fsmonitor
daemon prevented the release of our locks, resulting in errors for some
users reported in #13521.
However, the fix from #13586 set `core.fsmonitor` to `false` too often.
This is not needed for taps, or when `HOMEBREW_REPOSITORY` is different
from `HOMEBREW_PREFIX`. The issue in #13521 stems from the fsmonitor
daemon preventing the release of our locks, so there is no need to
prevent the daemon from monitoring repositories that don't contain our
lock files.
- The GitHub list commits API now supports this filtering
(https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-commits--parameters),
because I wrote it. :-)
- Authoring a commit and committing a commit are two separate concepts: author
is the person who wrote the code and, in old parlance, the committer is the
person who applied the patch (remember when we sent patches to mailing lists?).
- In practice for us in Homebrew, this occurs when we make a change in GitHub's
web editor, or, more obviously, when BrewTestBot pushes `homebrew-core`
commits from users (then, `BrewTestBot` is the `committer`).
This renames `simple_content` to `content_simple`, which makes the
`content_*` variable name convention more consistent (as is in the
`Xml` strategy tests).
This setup mimics the `#parse_xml` method that was implemented in the
`Xml` strategy. Isolating the parsing code means that other strategies
can take only what they need from `Json` (i.e., it's not required for
them to use `Json#find_versions`).
