Changing the way gitRevision works

[KDean-Dolphin]

Search Terms

gitRevision branch commit

Problem

I have a documentation project separate from the libraries I'm writing. My goal is to have documentation for every production version of my code (e.g., 1.0.17, 1.1.3, 1.2.1, 2.0.23, 2.1.0, etc.), each in its own directory.

When I run TypeDoc against the libraries, the documentation links to the version of the source code at the latest commit for each library. This means that every time I run TypeDoc, every generated file needs to be committed.

Presently, I'm setting gitRevision to "main", though without the changes proposed below I will likely set it to "1.0", "1.1", "1.2", "2.0", "2.1", etc. as I get closer to production.

Suggested Solution

What I'd like to see is an option either to use the current branch name ("main", "1.0", "1.1", etc.) or to use the latest commit for the file itself, not for the repository. The first option generates a completely new set of documentation for each branch, which I'm OK with, whereas the latter limits commits to only those files that have changed (which means that stable files may not see a new documentation revision for a very long time, barring other configuration changes).

Thanks.

[Gerrit0]

I have added a {branch} special value for the gitRevision option to allow requesting that TypeDoc use the current branch name.

Using the latest commit for the file isn't feasible generally as it means that TypeDoc would have to run a git command for every referenced file in the output documentation, which will be horrendously slow in projects which have thousands or tens of thousands of files (I've seen it!)