This also means that this field should not become a `List<String>`,
though it would make sense to create a new type for it (which could be
converted into `List<String>` in two different ways, with or without
quoting).
It would be good to include the word "divergent" in the log when a
change is divergent, since users are often unsure what's happening when
they see a divergent change, and giving them a term to search for would
be helpful. However, I don't think it looks good to put this label next
to the change ID itself if both are the same color, since it ends up
being hard to distinguish from the change offset at a glance. Also,
putting the label next to the change ID also messes up the alignment of
fields in the log. Therefore, I think it looks better to put the
"divergent" label at the end of the line.
Since divergence and hidden commits are similar, it makes sense for both
labels to be in the same place, so I also moved the hidden label to the
end for consistency.
One downside is that the labels are less obviously connected with the
change ID itself due to them being farther apart. I think this could be
fine, since they are still visually connected by being the same color.
Several commands accept both positional arguments and a `-r` flag for
specifying revisions. The `-r` flag exists for consistency with other
commands, but was previously hidden from help output.
Instead of unhiding `-r` (which would clutter the Options section),
document the aliasing by adding `[aliases: -r]` to the positional
argument's help text. This makes the relationship discoverable while
keeping the help output clean.
Commands updated: abandon, describe, duplicate, edit, metaedit, new, show
Fixes#8104
The help text for `jj split` was confusing about what happens to
"selected" vs "remaining" changes, especially with the `-o/-A/-B` flags.
This change:
- Adds ASCII diagrams showing the commit graph transformations for
default split, --parallel, and -o/-A/-B modes
- Clarifies that by default, selected changes stay in the original
commit while remaining changes go to a new child
- Explains that with -o/-A/-B, selected changes are extracted to a
new commit at the destination while remaining changes stay in place
- Improves the --message flag description to clarify it applies to
the first commit (containing selected changes)
- Adds explanatory text to the -o, -A, and -B flag descriptions
The goal of this change is to unify defaults of string patterns in revsets and
command arguments. Glob is a good default because it's largely the same as exact
matching, and we can easily express substring patterns with globs.
The hint for "jj git fetch -b<glob>" is deleted since exact:<glob> is now
required in order to trigger the error.
This patch also updates help of clone/fetch --branch patterns. Glob and operator
support in refspecs is limited.
When using `--interactive` or path arguments, it wasn't clear from the
help text what happens to the changes that aren't selected. This adds
an explanation to the main command documentation and updates the flag
and argument descriptions to use "current commit" instead.
Fixes#6666
These two are the last commands which don't support logical operators in string
patterns. The old <kind>:<name>@<remote> syntax had various problems including:
1. substring patterns look weird (e.g. `substring:x@y` means `*x*@*y*`)
2. cannot express "all but <name> for all remotes" (e.g. `(~gh-pages)@(*)`)
In addition to that, the revset parser doesn't support `<name>@<remote>`
prefixed by `<kind>:`.
This patch introduces separate --remote argument to address these problems. The
default is `glob:*` (or `~git`), so we wouldn't have to specify the remote in
many cases. One caveat is that `jj bookmark track` is not idempotent if there
are multiple remotes:
# there are two remotes: origin and upstream,
# and only foo@origin exists
$ jj bookmark track foo
# tracks foo@origin and creates new local bookmark foo
$ jj bookmark track foo
# tracks absent foo@upstream as we now have a local bookmark
This is wild. We might want to add a flag or a new command to track absent
remote bookmarks to push.
"Unmatched names" warnings are now emitted for bookmark and remote names
separately. To keep the implementation simple, the search space isn't restricted
by the other parameter. For example, "jj bookmark track foo --remote=bar" won't
show a warning if "foo" exists locally or in any remote.
Closes#4260
The help doc for `jj squash` is not explicit about what happens if there are no
options supplied to the command. Improve the help doc to explain the said
situation.
Fixes: #8241
While divergence is talked about in the documentation, few places actually
mention how divergent changes are displayed. I've added such notes to the help
out put of `jj log`, the glossary, and added an example to the guide we have on
divergence.
Fixes#6365
Since the specified patterns are no longer guaranteed to match at least one
remote branch, the default (remote) branch is taken into account if exact
patterns match nothing. I think this is better because `-b glob:*` is now
identical to the default.
In order to write config settings of tools for jj fix, you needed
information that were split in the `jj fix --help` text and
`jj help -k config` (or the respective web-pages).
Move every bit of information that is important to know to write
`jj fix` configurations in the config page. This avoid to have to
maintain the information up-to-date in two places.
Organize the help text of `jj fix` with several chapters.
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.
This adds support for tracking ignored and oversized files with `jj file track`.
Previously, `jj file track` would silently fail to track files that were ignored by
`.gitignore` or larger than `snapshot.max-new-file-size`. This commit introduces an
`--include-ignored` flag that allows users to explicitly track these files.
## Implementation
Added a `force_tracking_matcher` field to `SnapshotOptions` that overrides ignore rules
and size limits. When `--include-ignored` is specified, the file pattern matcher is
passed as `force_tracking_matcher`, allowing three checks in `FileSnapshotter` to bypass
their usual restrictions for directory ignores, file ignores, and file size limits.
## Tests
- `test_track_ignored_with_flag`: Verifies `.gitignore`d files can be tracked
- `test_track_large_file_with_flag`: Verifies oversized files can be tracked
- `test_track_ignored_directory`: Verifies ignored directories can be tracked recursively
# Checklist
If applicable:
- [ ] I have updated `CHANGELOG.md`
- [x] I have updated the documentation (`README.md`, `docs/`, `demos/`)
- [ ] I have updated the config schema (`cli/src/config-schema.json`)
- [x] I have added/updated tests to cover my changes
As we have discussed many times on Discord and GitHub, `--destination`
is not a great name because `--insert-before` and `--insert-after` are
also destinations. The most popular alternative seems to be
`--onto`. We already use that term in descriptions in several places,
such as in the help text for `rebase -d` where we say "The revision(s)
to rebase onto". This patch therefore renames the `--destination` flag
to `--onto`.
The short name naturally becomes `-o`. That is perhaps a little
unfortunate because it's a common short name for `--output <file>`
arguments, but we don't use that anywhere so it seems fine.
Perhaps we should also rename `--source` (used by `rebase` and `fix`)
to something else. Perhaps the most obvious name is `--descendants`,
but the short form would be `-d`, which is of course already taken by
`--destination` in the case of `rebase`. Either way, I'm leaving that
rename for later. It would be good to do it before next release if we
are going to do it, though.
Closes#7941
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.
in clap, the visible_aliases, e.g. '[aliases: --after]' are shown at
the very end, which makes it confusing if you're reading from top to
bottom.
aliases are currently omitted entirely from the man pages, making it
confusing to see undocumented aliases being used.
Just moments ago, I ran into a case where I wanted to change both the
author and committer of a change. I knew about the new `jj metaedit`
command, but until now that only gave me the ability to update the
author of my change, so the committer would remain the same. My only
other option was to reach for `jj desc ... --reset-author`, which has
a deprecation warning:
Warning: `jj describe --reset-author` is deprecated; use `jj metaedit --update-author` instead
In spite of that warning, this had the desired effect: both the author
and committer were updated.
So I figured I'd help `metaedit` grow these flags so it can be a _true_
replacement for `jj desc --reset-author`.
---
The above all happened before I was kindly informed in Discord
(https://discord.com/channels/968932220549103686/1431315533164314674)
that `jj metaedit --update-committer-timestamp` should do what I was
hoping for, which I had initially disregarded and never tried because
the help text originally said:
This updates the committer date to now, without modifying the committer.
However, after trying it out, I noticed it actually _did_ modify the
committer.
So, I set out to improve the situation by renaming the flag (so it's
not partially-wrong: it does update the committer timestamp, as well as
everything else about the committer) and improving the help text in the
various flags.
---
In no particular order, thanks to:
* obtuse, for informing me that the `--update-committer-timestamp`
flag does what I wanted in the first place
* gaetan, for pointing out that my way of thinking was not quite meshing
with how jj does things (every modification will update the committer)
* Martin, for the new flag name
This new command lets you turn a non colocated git repo into a colocated repo or vice-versa (by using the `jj git colocation enable` and `jj git colocation disable` commands respectively).
These commands simply implement the instructions found in https://github.com/jj-vcs/jj/blob/main/docs/git-compatibility.md#converting-a-repo-into-a-co-located-repo
You can also call `jj git colocation status` to show the current colocation status and `jj colocation` to show a help message (with the list of sub-commands).
When cloning with the branch option:
- Only the specified branch will be fetched
- The trunk alias is only set if the specified branch happens to be the default branch
- The clone fails if the branch does not exist in the remote
This is a stripped-down version of cmd_bookmark_set(). Since tags shouldn't
usually be rewritten, I've made it fail on updating existing tags by default.
