pr-automerge: pluralize message only when needed

[dtrodrigues]

• 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 tests with your changes locally?

---

Don't pluralize message when there is only one matching pull request.

[reitermarkus]

Suggested change

	ohai "#{prs.size} matching pull #{"request".pluralize(prs.size)}:"
	ohai "#{prs.count} matching pull #{"request".pluralize(prs.count)}:"

[dtrodrigues]

I don't mind changing, but why is count preferred to size?

[reitermarkus]

It reads nicer. 😉

[maxim-belkin]

It reads nicer. 😉

It sounds like a personal preference that we shouldn't be casting on other maintainers.

[dtrodrigues]

I'd rather not change existing code if there isn't a good reason, so I'll leave it as is.

[reitermarkus]

It's not really a personal preference: You can count multiple PRs, but you can't measure their size.

[MikeMcQuaid]

I think it's fine to suggest personal preference. I agree this is easier to read. It'd fine to me either way so I'm approving but I'd rather see "comment and approve" than maintainers such as @reitermarkus being encouraged to not leave these sort of (useful) comments.

[maxim-belkin]

I think it's fine to suggest personal preference.

It is sure fine to make suggestions based on personal preferences, but they should be explained (initial comment had no accompanying explanation) and provide at least some reasoning. I agree with the explanation provided later that one can count PRs but can't measure their size but I disagree with "it reads nicer".

[MikeMcQuaid]

I think it's fine to suggest personal preference. I agree this is easier to read. It'd fine to me either way so I'm approving but I'd rather see "comment and approve" than maintainers such as @reitermarkus being encouraged to not leave these sort of (useful) comments.

[dtrodrigues]

Prior to the more in-depth explanation from @reitermarkus, it wasn't clear to me why count was better and it seemed preferable to stay with the code that existed prior to the PR if there wasn't a strong reason to change it. Given the more detailed explanation, I agree that count does flow more nicely in the code, so I've made the change.