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.
Almost everyone calls the project "jj", and there seeems to be
consensus that we should rename the crates. I originally wanted the
crates to be called `jj` and `jj-lib`, but `jj` was already
taken. `jj-cli` is probably at least as good for it anyway.
Once we've published a 0.8.0 under the new names, we'll release 0.7.1
versions under the old names with pointers to the new crates names.
I wasn't quite happy with `jj support` but I couldn't think of
anything better when I moved the commands from `jj debug` in
e2b4d7058d. Thanks to @ilyagr for suggesting `jj util`.
The `jj debug` commands are hidden from help and are described as
"Low-level commands not intended for users", but e.g. `jj debug
completion` is intended for users, and should be visible in the help
output.
Our installation instructions don't currently work with Rust < 1.64
because `clap` updated their MSRV to 1.64, and `cargo install` without
`--locked` bypasses `Cargo.lock` and selects the version of `clap`
that needs Rust 1.64.
I added support for using a vendored OpenSSL in dbadbd68c0. That was
in order to get the musl binary to work. However, it shouldn't be
needed on most platforms, and we've had a few reports of issues caused
by it. Let's disable it by default and enable it specifically when
building the musl binary instead.
Our readme says that pull request require too many manual steps. I
think that refers to the manual abandoning of merged commits that was
necessary before 57ba9a940976; I think the workflow works reasonably
well these days. So let's avoid scaring away potential new users by
mentioning that old problem.
The demos don't need to be animated - the user wouldn't miss anything
if they skipped to the end. So let's just show the full output so the
user can read through it at their own pace. We could use plain text,
but I think the colors are helpful, so I went with screenshots.
Closes#166.
