This behavior is similar to "jj git push". If we add "jj git push --tag" option,
it would disable the default revset.
No changelog entry is added because "jj git fetch --tag" isn't released yet.
It's also experimental.
- Added example command showing --author flag usage to metaedit.rs
The docs show examples for other similar commands, but not for the
author command. Since the format is not obvious an example is helpful.
When `git.colocate` config is true (the default), the `--git-repo` flag
for `jj git init` was silently ignored. This happened because the
colocate logic was checked before the --git-repo logic:
let colocate = if command.settings().get_bool("git.colocate")? {
!args.no_colocate // true unless --no-colocate passed
} else {
args.colocate
};
Then in `do_init()`:
let init_mode = if colocate {
// takes this branch, ignoring --git-repo!
} else if let Some(path_str) = git_repo {
// --git-repo handling never reached
}
This meant `--git-repo` was simply ignored unless `--no-colocate` was also
passed.
This is a regression from when colocation became the default. Before
that change, `--git-repo` worked without any additional flags because
`colocate` defaulted to false. The fix preserves that original behavior
by checking for `--git-repo` first and setting `colocate = false` when
it's provided, allowing the --git-repo code path to be reached.
This change adds the ability to provide a description for the commit
when a workspace is added.
Example:
```
$ jj workspace add -m "wip bugfix" --name bugfix ../bugfix
Created workspace in "../bugfix"
Working copy (@) now at: xmskztnv 564c419d (empty) wip bugfix
Parent commit (@-) : zzzzzzzz 00000000 (empty) (no description set)
```
Currently, when a workspace is added, the new (empty) commit that is
created has no description set.
This change to `workspace add` mirrors the option to the `new` command,
which can take zero or more `-m/--message` flags for setting the
description for a new commit. The same logic for creating the new commit
for a workspace applies in terms of parent revisions, so this change
brings `new` and `workspace add` closer together in terms of CLI
affordances.
Similary to `new`, this change permits multiple message flags to be
supplied on the CLI. It also retains the behavior of not otherwise
creating a description of just trailers if no message flag were supplied
but trailers were set.
This allows `jj workspace root` command to take an optional workspace
arg to print the root directory of that workspace, while defaulting to
the current workspace.
We allow this by creating a new `workspace_store` which has a separate
entry for each workspace containing its name and root directory. This
store is created during initiation of the repo and is maintained
whenever `add`, `forget` & `rename` workspace subcommands are executed.
CAUTION: Moving a workspace path will not sync the path stored in the
workspace store.
CAUTION: Specifying `jj workspace root` with a workspace created before
this will result in an error.
When `.jj/working_copy/checkout` refers to an operation that's not in
the op heads, there can be a few different cases. It's typically
simply behind or ahead, but it can also be a sibling. Until we
implement `--no-commit-transaction`, it would indicate a bug if that
happens. However, it does happen sometimes (rarely) at Google where we
can fail to flush the update of the op heads to the server for some
reason, but since we optimistically assume that it will succeed, we
update the working copy to refer to the operation before we have
flushed the op-head update. When in this state, we currently print an
error saying that the repo operation is a sibling of the working
copy's operation, but we don't provide a way of fixing it. This patch
provides a command for fixing this state. It will also be useful once
we have `--no-commit-transaction` (which will presumably print the
un-integrated operation id).
We currently call the process of adding an operation to the operation
heads "publish" in the code. I still went with "integrate" here
because I think it's clearer. If we go with "integrate", we can rename
the internal uses of "publish" to match in a follow-up. Other
reasonable verbs include "record" and "accept". Or we can of course go
with "publish".
This will be needed in order to write CLI tests of tags fetched to @<remote>
namespace. --remote and --tracked are hidden for now because they are useless
without remote tags support. --all-remotes is used as a flag to show both local
and @git remote tags. No changelog entry is added because this feature is
useless except for debugging or testing.
By explicitly naming the bookmark to push, users already express their
intent to push that particular bookmark. Requiring them to express
that intent a second time by manually marking the bookmark as tracked
is therefore unnecessary.
There is an exception if the bookmark is already tracked with some
remote. In that case, the user may have forgotten to specify --remote
and creating the bookmark on a different remote may be a mistake.
closes#8387
This brings `jj parallelize` in line with other commands such as `jj new` and `jj
duplicate` that take a `-r` option in addition to the positional argument.
This isn't exactly the same as what the reporter proposed in #8030, but it
should usually work since versions are roughly assigned in chronological
order. We can add --sort=name-as-version later if needed.
This patch also adds missed drop(formatter).
Closes#8030
rfc2822, and by extension chrono's parser for rfc2822, only supports a
limited number of timezones (4.3, "Obsolete Date and Time"). JST is not
one of the enumerated zones.
Current fix is to just use a supported time zone in the example. It's
still possible to use a non-enumerated timezone with a human-readable
format by giving the timezone offset directly (`-0800` for PST).
fixes#8421
We have had two users at Google in the last few days how have wondered
why there's no documentation for the `-d` flags. Of course, the answer
is that they're deprecated, but given how long they have been
available, many users are already use them frequently. Perhaps they
then look at `jj rebase --help` to figure out what `-d` really means
and how it's different from `-A` or `-B`. It's the confusing that they
are not mentioned at all.
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.
