As a follow-up to #8115, this moves all references in the codebase to use the new website.
I didn't update the older CHANGELOG entries because I figured they're intended
to be immutable.
Currently there are instructions on how to setup jj to work with GitHub,
but not Gerrit, which seems to be very popular with the jj community.
Add a gerrit.md file to help users discover the jj gerrit subcommand.
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>
