Provide a bit more detail about the JJ to Gerrit change mapping, advice
on handling splits and squashes, as well as the existing FAQ
configuration for adding Change-Id directly to change descriptions.
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
This adds a command that automatically bisects a range of commits
using a specified command. By not having the interactive kind
(e.g. `jj bisect good/bad/skip/reset`), we avoid - for now at least -
having to decide where to store the state. The user can still achieve
interactive bisection by passing their shell as the bisection command.
Closes#2987.
After a change has been accidentally modified, the user may want to
recover the original revision with the same commit ID if it was pushed
to a remote, not just restore the original contents.
Instead of using `jj restore` to restore contents, recommend using `jj
new <PREVIOUS_ID>` to unhide the original commit. This strategy works
whether or not the user cares about the original commit ID.
* Added an explanation for why reverting a merge often results in an
empty commit.
* `jj revert <merge>` requires `-r`.
* Fixed backwards description of merge direction (compared to what
the graph shows).
* Minor copy editing.
This is idiosyncratic to new users coming from Git, since `jj revert <merge>` does not
usually do what users want. Maybe a followup could be adding a
warning in `jj revert`.
The explanation is from a Discord message from Austin.
The FAQ entry explaining why `jj log` doesn't show all commits
explained that the behavior is configurable but it didn't explain what
the rationale for not showing all commits is. Users coming from Git
are used to seeing all commits and probably read this FAQ entry to
find an answer. We don't want them to just update their config without
understanding why we have the default we have.
It was requested on Discord once.
The result is almost a tutorial; we could consider actually moving it into the
tutorial and providing a link in the FAQ. That could be done separately.
The `jj` commands outputs are faked in a few, hopefully inconspicuous, ways.
Hopefully, this is not distracting.
The example became incorrect when `jj config set` stopped promoting
values with apostrophes to strings in 3f115cb. Use a TOML literal
string to fix it.
* Suggested `watch --color` as recommended by @ilyagr
* Answered monitoring `jj log` with watch and TUIs
* Minor wording fix.
* Adjusted watch(1) and hwatch links as suggested by @ilyagr
Signed-off-by: Tim Janik <timj@gnu.org>
The current instructions ask the reader to convert the merge commit into
a single-parent commit, then create a new merge.
It is probably simpler to follow instructions for inserting a new commit
before the merge commit.
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.
It's a pretty frequent request to have support for turning off
auto-tracking of new files and to have a command to manually track
them instead. This patch adds a `snapshot.auto-track` config to decide
which paths to auto-track (defaults to `all()`). It also adds a `jj
track` command to manually track the untracked paths.
This patch does not include displaying the untracked paths in `jj
status`, so for now this is probably only useful in colocated repos
where you can run `git status` to find the untracked files.
#323
It seems everyone agrees that `obslog` is not an intuitive name. There
was some discussion about alternatives in #3592 and on #4146. The
alternatives included `evolution`, `evolutionlog`, `evolog`,
`rewritelog`, `revlog`, and `changelog`. It seemed like
`evolution-log`/`evolog` was the most popular option. That also
matches the command's current help text ("Show how a change has
evolved over time").
The question "How do I avoid committing changes to files?" comes up a lot in
chat, and the solution is not obvious. It will be useful to have a description
with an example we can link to.
The wording of the similar question "How can I keep my scratch files in the
repository?" was tweaked to emphasize the difference between keeping untracked
files in the workspace and keeping changes tracked files out of published
history.
In the FAQ question "How do I integrate Jujutsu with Gerrit?", the link
to the glossary entry for "co-located repos" was pointing to the entry
for "change-id".
This question is mildly popular on Discord so it's finally time to have an answer.
We should do something better in the future but the current solution is good enough for today.
cc @thoughtpolice
