git-sizer Don't search/list every single repo reference when explicit references are provided

Now that we can provide explicit roots to git-sizer, we don't want to look for other references than the one provided.

Sep 25 '23 13:09 elhmn

It would be a nice optimization not to run git for-each-ref at all in the case that no references are being scanned. That might make a significant difference to the runtime in a repository that has a lot of references if only a small part of the history is being scanned.

But this PR as currently written introduces a couple of rough edges:

In the case that both references and objects were specified, the old code scans both. For example,
```
 git-sizer --tags 'HEAD@{1.week.ago}'
```
scans objects that are reachable from tags and also objects that are reachable from the reflog entry for HEAD from a week ago. I think that the optimization should only be used if an argument was specified AND no tag-related options were specified (which is the behavior documented in the --help output).
When this optimization is triggered, the output still includes the lines
```
 | * References                 |           |                                |
 |   * Count                    |     0     |                                |
```
The count usually lists the total number of references (including those that were not selected). It is misleading to say that this count is zero only because we didn't bother to read the references at all. I think it would be better not to output these lines at all when the optimization is in effect (and analogously for the JSON output).

The textual output is defined in HistorySize.contents(). This function already has some code that adds an item for each reference group (in rgis). It could take an additional bool parameter and based on that include or omit the whole "References" section. It's a little bit awkward because of the way sections are constructed; let me know if you want some ideas for how that could be wired up.

Sep 25 '23 16:09 mhagger

(To be clear, the progress meter was already inaccurate before this PR. It just wasn't so obvious, because the references were being scanned and counted as well.)

Dec 14 '23 00:12 mhagger