This was requested by @lilyball on Discord. I still think we should create a blog longterm
so we can announce stuff and run surveys, but this small step won't block it.
With this enabled, clicking on a content tab will activate all tabs with the same label.
For example, clicking on any `Dynamic` tab on the docs/install-and-setup.md page will
show each shell's command to enable dynamic completions all at once. See [0] for more
details.
[0]: https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#linked-content-tabs
This allows text typed into the search box to persist across page navigation, which is
useful when users look up a term but aren't sure on which page they will eventually find
the relevant information. See the [`mkdocs-material` docs][mm-docs] for more
information.
[mm-docs]:
https://squidfunk.github.io/mkdocs-material/setup/setting-up-navigation/#instant-loading
This was taken out of the "Jujutsu from first principles" doc in another PR. It represents some of the common ideas
which the project had around a year ago.
I think this can be modernized if the maintainers want it.
This avoids having to escape double and single quotes used within page names. One page has double quotes in its name in the current state, and another will have a single quote in its name in the next commit.
The warning this suppresses is shown by `mkdocs serve`:
```
INFO - The following pages exist in the docs directory, but are not included in the "nav" configuration:
- paid_contributors.md
```
We can alternatively add that doc to nav.
This is the result of a lot of back and forth, the weekly efforts of the
governance working group, consisting of:
- Martin von Zweigbergk (martinvonz)
- Waleed Khan (arxanas)
- Emily Shaffer (nasamuffin)
- Austin Seipp (thoughtpolice; yours truly)
Many thanks as well to emeritus member Khionu Sybiern, who helped kickstart this
whole process.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This makes the pre-release header bar into a steely blue-grey color and
changes its label, while the header for the stable docs (and past
release docs) remains indigo (blue). The goal is to make it easier to
tell prerelease docs and regular docs apart with a glance. I also
considered using a favicon with a different background, but perhaps
that's not as useful as changing the header color.
See https://github.com/jj-vcs/jj/pull/5614 for screenshots and
https://squidfunk.github.io/mkdocs-material/setup/changing-the-colors/#primary-color
for some more possibilities. "Deep purple" or "brown" are the closest
runners up to "blue grey" in my mind.
This can be tested with
```
MKDOCS_PRIMARY_COLOR="blue grey" MKDOCS_SITE_NAME="Jujutsu docs (prerelease)" uv run mkdocs serve
```
-----------
We could also want to make the historical versions more easily
distinguishable from the `latest` docs, but that would be more
difficult. We'd either need to rely on javascript or to rebuild the
*previous* version of the docs in addition to the new one on every
release.
See [mkdocs-material banner docs] for a javascript apporach (which would
still need some care in implementing, since we probably want the
prerelease version to either not have a banner or to have a different
banner).
[mkdocs-material banner docs]:
https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/?h=version#version-warning
In order for the governance working group to make progress establishing
jj's governance structure, we need the approval of the jj community.
Set up a temporary voting process to get that approval.
Additionally, set up a governance dir for other governance-related
documentation to sit in.
Later, when we have a permanent governance structure and enough policy
to let the community make changes without needing the governance working
group, we can delete this document.
Jujutsu's branches do not behave like Git branches, which is a major
hurdle for people adopting it from Git. They rather behave like
Mercurial's (hg) bookmarks.
We've had multiple discussions about it in the last ~1.5 years about this rename in the Discord,
where multiple people agreed that this _false_ familiarity does not help anyone. Initially we were
reluctant to do it but overtime, more and more users agreed that `bookmark` was a better for name
the current mechanism. This may be hard break for current `jj branch` users, but it will immensly
help Jujutsu's future, by defining it as our first own term. The `[experimental-moving-branches]`
config option is currently left alone, to force not another large config update for
users, since the last time this happened was when `jj log -T show` was removed, which immediately
resulted in breaking users and introduced soft deprecations.
This name change will also make it easier to introduce Topics (#3402) as _topological branches_
with a easier model.
This was mostly done via LSP, ripgrep and sed and a whole bunch of manual changes either from
me being lazy or thankfully pointed out by reviewers.
This avoids an MkDocs warning.
I put it into Design Docs, since people who follow the link to the
roadmap might be interested in those.
It's not a perfect place for it, but it seems better than "Technical
Details" or "Contributing" (which might make people think that they have
to read or follow the roadmap before contributing).
This adds the basic outline of _when_ a Design Doc should be written. See the next
commit in the stack for the blueprint.
By adding this we hopefully can prevent unnecessary churn from new and longtime contributors,
when they want to add a major feature or rewrite a core part of Jujutsu. The text is written
as a guideline, not a rule.
See https://github.com/martinvonz/jj/pull/3723 for a screenshot.
This will make it clearer to the users that the "latest" and "v0.??.?"
are the same even if the former does not redirect to the latter (but has
identical contents).
MkDocs material lists the *first* alias for each version, so I also
added a "nightly" alias for "prerelease". Otherwise, users would see the
"main" alias, and might get confused whether they should use "latest" or
"main" docs if they don't realize it's named after the "main" branch.
(Upon testing, it still shows "main" for now, but it should be possible
to fix this after this PR is merged by reordering the aliases directly
in `versions.json` on the gh-pages branch)
Show our positive reviews to the world. It's also not completly serious, in a similar fashion to
Phabricator.
Co-Authored-By: Austin Seipp <aseipp@pobox.com>
I am using a very hacky approach, using `insta` to generate the markdown help.
This is based on a lucky coincidence that `insta` chose to use a header
format for snapshot files that MkDocs interprets as a Markdown header (and
ignores).
I considered several other approaches, but I couldn't resist the facts that:
- This doesn't require new developers to install any extra tools or run any
extra commands.
- There is no need for a new CI check.
- There is no need to compile `jj` in the "Make HTML docs" GitHub action,
which is currently very fast and cheap.
Downside: I'm not sure how well MkDocs will work on Windows, unless the
developer explicitly enables symbolic links (which IIUC is not trivial).
### Possible alternatives
My next favorite approaches (which we could switch to later) would be:
#### `xtask`
Set up a CI check and a [Cargo `xtask`] so that `cargo xtask cli-help-to-md`
essentially runs `cargo run -- util markdown-help > docs/cli-reference.md` from
the project root.
Every developer would have to know to run `cargo xtask cli-help-to-md` if
they change the help text.
Eventually, we could have `cargo xtask preflight` that runs `cargo +nightly
fmt; cargo xtask cli-help-to-md; cargo nextest run`, or `cargo insta`.
#### Only generate markdown for CLI help when building the website, don't track it in Git.
I think that having the file in the repo will be nice to preview changes to
docs, and it'll allow people to consult the file on GitHub or in their repo.
The (currently) very fast job of building the website would now require
installing Rust and building `jj`.
#### Same as the `xtask`, but use a shell script instead of an `xtask`
An `xtask` might seem like overkill, since it's Rust instead of a shell script.
However, I don't want this to be a shell script so that new contributors on
Windows can still easily run it ( since this will be necessary for the CI to
pass) without us having to support a batch file.
#### Cargo Alias
My first attempt was to set up a [cargo alias] to run this, but that doesn't
support redirection (so I had to change the `jj util` command to output to a
file) and, worse, is incapable of executing the command *in the project root*
regardless of where in the project the current directory is. Again, this seems
to be too inconvenient for a command that every new PR author would have to run
to pass CI.
Overall, this just seems a bit ugly. I did file
https://github.com/rust-lang/cargo/issues/13348, I'm not really sure that was
worthwhile, though.
**Aside:** For reference, the alias was:
```toml
# .cargo/config.toml
alias.gen-cli-reference = "run -p jj-cli -- util markdown-help docs/cli-reference.md"
```
### Non-alternatives
#### Clap's new feature
`clap` recently obtained a similarly-sounding feature in
https://github.com/clap-rs/clap/pull/5206. However, it only prints short help
for subcommands and can't be triggered by an option AFAICT, so it won't help us
too much.
[Cargo `xtask`]: https://github.com/matklad/cargo-xtask
[cargo alias]: https://doc.rust-lang.org/cargo/reference/config.html#alias
