brainstorming branch globs and task format cleanup

# Wiki and Tasks

These markdown files are used to keep track of tasks like an issue tracker.

Right now I'm just using this space to brainstorm improvements to the repo.
The goal is to eventually have extensive documentation here.

> Note: to link to other pages, add a `.html` to the end of the page you
> are linking to. When the site is rendered, markdown files get rendered
> at a URL like `path/to/file.md.html`. So to link to that page, do
> `[link text](./path/to/file.md.html)`.

## Ideas and Works in Progress

- [ ] Branch Globs
  - Goal: allow users to specify a glob pattern (like `deploy/**`) instead of spelling out every branch name in full in their config file
  - [Project page](./projects/branch-globs.md.html)

- [ ] Better Template Readability
  - Goal: Do not simply have a bunch of strings as the HTML for the default virtual
    template. Maybe look into using mithril for server-side rendering?
  - This will also make the code look much less "ewww" for possible new contributors.
  - Also allows typescript to help out more.

- [ ] Tag snapshots
  - Goal: have HTML pages generated for user-specified tags in the repo, not
    just each branch head.

- [ ] Clone repo at first, rather than at the end
  - git branch: `clone-early`
  - [Project page](./projects/clone-early.md.html)
  - Goal: Clone the repo before site generation starts. Use this cloned repo for all repo actions.
    - As a side benefit, this should allow users to clone from a remote repository (like on github) and use their static HTML site as a mirror of that. E.g. the `location` for the repo in the plugin config could be a remote URL.
    - ==This might need to be done before branch globs and tags==

- [ ] Create links consistently with some kind of nav or link helper
  - Goal: Links to various pages are being manually created with a hodgepodge
    of splitting and slugifying strings. Create an easy and consistent way for
    the virtual template to get a link to the other pages.
    - Should be used in places like `file.ts`, `files.ts`, etc.
    - Part of this task should also be to avoid slugifying parts of the link
      that we don't need to. E.g. right now, a folder like `wiki_and_tasks`
      will get changed to `wiki-and-tasks` (with hyphens instead of underscores)
      for the URL. But underscores *are* valid for using in a URL, and also,
      there could also be a folder called `wiki-and-tasks` with hyphens, and
      they would both be able to exist in the repository.

# Branch Globs

> Goal: allow users to specify a glob pattern (like `deploy/**`) instead of spelling out every branch name that will be included in their repository.

Git branch: `branch-globs`

- Where are branches currently pulled?
  - There is `getBranchNames` in `src/repos.ts`.
  - If the branch is an object, like `{ glob: string, max: number}`, then
    we should query for get all branches from the main repository and see
    if any match.
  - There could be a branch that matches multiple globs
  - Put branches in a hash, with keys being the glob that matched them.
  - Remove the oldest branches (by last commit?) to limit to the `max` number
  - Then merge the branches into a set so there are no duplicates -- we don't
    actually care which glob matched the branch, we just want to be able to
    enforce the `max` value for a glob.

Use node's `path.matchesGlob()` method: https://nodejs.org/docs/latest/api/path.html#pathmatchesglobpath-pattern.

```js
path.matchesGlob('/foo/bar', '/foo/*'); // true
```

# Clone Early

> Goal: Repoviewer should clone its own copy of the repository in
> a "before" hook, instead of an "after" hook. Then it should use
> that copy of the repo for all of its operations when generating
> the site. This is also the point where it can figure out which
> branches match the user's provided branch glob names. (See
> [branch globs project](./branch-globs.md.html).)