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.
Colocation is about sharing the working copy between jj and git. It's
less important where the repo is stored. I therefore think we should
not call it "colocated repo". I considered renaming it to "colocated
working copy" but that sounded awkward in many places because we often
talk about the whole workspace (repo + working copy), so "In colocated
workspaces with a very large number of branches or other refs" sounds
better than "In colocated working copies with a very large number of
branches or other refs".
Once we support colocate workspaces in non-main Git worktrees, I think
this rename will be even more relevant because then all those
workspaces share the same repo but only some of them may be colocated.
As suggested by @PhilipMetzger
The word "grey" is whitelisted because
- we have a contributor of that name
- we use a library that uses "Grey" as a member of an enum
- I refuse to believe "grey" is not US English
New users (especially ones unfamiliar with CLI programs) intuitively
expect `jj undo` to work the same way the "undo" functionality of
typical GUI applications do. That means, running `jj undo` multiple
times should restore progressively older states of the repository
one-by-one.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
It has seriously gone out of date, so update it for 2025 and mention the new `jj-vcs` org.
The suggestion came from melutovich in the #jujutsu Libera IRC chat.
It is important to mention tracking branches and listing branches. This topic is important now that `jj log` does not show branches
`jj git clone` says it fetched by default.
The demo has become more about navigating a Git remote, so I reworded
the README accordingly, shifting the focus more to "Git remote
compatibility" and away from "We include a Git repo". Both are
important, but these skills seem important for beginners.
The Pijul maintainer has opinions that I don't understand about how we
mention Pijul (they consider the current mentions offensive as
"bashing Pijul"). Let's just remove the references so we don't have to
deal with it. I think the references to Darcs we already had in most
of these places are sufficient.
This bundles all Jujutsu related media (the talk, its slides and the three articles we were featured in)
into a section.
Also update the news section to mention the recent deprecations and the three articles we recently
were featured in.
Thanks to everyone who wrote one.
Apparently this previously-beta markdown syntax from GitHub "graduated" to a
full feature in such a way that it it actually regressed in features, so doing
this `[!WARNING]` inline inside of a list is no longer valid. Sigh. Scoot it
up a level in the document, and just make it part of the section and not inside
the list.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
A coworker was having trouble finding a link to the jj Discord community. Add it to the top of the document, alongside the other badges, so it's easier to find.
Summary: What was going to just be some minor touch-ups to the existing content
ended in another rework of the frontmatter, this time primarily the sales pitch
and basic feature explanation.
The motivation here is simple: you should not just encounter a three-word noun
that is a hyperlink to pages with 1,000 words actually explaining the three-word
noun itself is. It's jarring!
Instead, the frontmatter is longer, expanding on each major selling point and
similarity to other tools. It actually *describes* the important, distinct
design decisions that tell you what the tool is and does, rather than just link
you around a bunch.
For example, one immediate thing is that calling jj a "DVCS" is actually kind
of odd when it later becomes apparent that you can have multiple data model and
commit backends; Google for example uses it in a more centralized manner than
others would via Piper/CitC. Calling it a "DVCS" is a bit strange in this sense
when *really* what we mean is that the Git data model allows independent copies
of the repo.
Overall I think this is *much* better for people who are just going to see the
README and may or may not bounce off immediately.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I9f0f78e56157ef434ec239710e00f3bd
Summary: Reintroduce 4acdf726 without spurious formatted changes. (This means I
don't have to go back over things with a fine comb.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I18ec68722362a2a64b99a368d3f25cf5
Summary: Just a small rework of the very top-level frontmatter. Now:
- Uses `<div>` to center things a little
- Adds top-level links to the new homepage, installation guide, and tutorial
- Reworks the disclaimer and 'Introduction' section. After all, a README should
first say what the project is! I think this reads much better.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Change-Id: I2d92a21650afec0640add3741d4f20c5
This allows the tutorial to reference them and will make it
easier to have different instructions for different versions.
We can later restore some instructions to the README, but I
think this is important since the installation instructions
do change in important (even if slight) ways from time to
time.
