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.
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
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.
Closes https://github.com/jj-vcs/jj/issues/7189
Colocated repos have some advantages and some disadvantages. On the
whole, I think making Git repos colocated by default is a better
trade-off, especially for new users. With the `git.colocate` setting,
(experienced) users can easily change this according to preference.
A non-exhaustive list of pros and cons of colocated repos:
pros:
* Many code editors show the changes one is currently working on based
on Git's "dirty worktree".
* There are a lot of tools that integrate with Git which don't work at
all in non-colocated repositories.
* There are a lot of Git features that Jujutsu doesn't have yet. When
users ask for them, the answer is usually: "Just colocate your repo
and run git directly for now." It's a strength that Jujutsu can focus
on what makes it special and not have to rush the reimplementation of
every niche feature of Git. Examples: `git rebase` tracking file
renames, `git bisect`, `git tag`, `git range-diff`, submodules.
cons:
* Jujutsu performs worse in colocated repositories with lots of refs,
because of the automatic `jj git import`.
* Colocated repos make branch@git references show up in Jujutsu output,
which is usually just aesthetically displeasing or possibly even
confusing to inexperienced users.
* Interleaving jj and (mutating) git commands can lead to confusing
situations. Examples:
* Creating a commit with git instead of jj will often leave a
duplicate "work in progress" commit in Jujutsu's log.
* Some IDEs periodically run `git fetch` in the background. This can
lead to conflicted branches and divergent change IDs, something many
people struggle with.
If you have multiple remotes to push to, you might want to keep some changes
(such as security patches) in your private fork. Git CLI has one upstream remote
per branch, but jj supports multiple tracking remotes, and therefore "jj git
push" can start tracking new remotes automatically.
This patch makes new bookmarks not eligible for push by default. I considered
adding a warning, but it's not always possible to interrupt the push shortly
after a warning is emitted.
--all implies --allow-new because otherwise it's equivalent to --tracked. It's
also easier to write a conflict rule with --all/--deleted/--tracked than with
two of them.
-c/--change doesn't require --allow-new because it is the flag to create new
tracking bookmark.
#1278
This makes it easier to work with multiple remotes at once while
tracking the default branch of the remote used to create the local
repository:
```shell
$ jj git clone --remote upstream https://github.com/upstream-org/repo
$ cd repo
$ jj git remote add origin git@github.com:your-org/repo
$ jj config set --repo git.fetch upstream
```
In the example above, `upstream` is the repository containing the
reference source code that you might want to patch, while `origin` is
your fork where pull-request will be pushed. The branch `main@upstream`
will be tracked.
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.
As far as I can see in the chat, there's no objection to changing the default,
and git.auto-local-branch = false is generally preferred.
docs/branches.md isn't updated as it would otherwise conflict with #2625. I
think the "Remotes" section will need a non-trivial rewrite.
#1136, #1862
The `--allow-large-revsets` flag we have on `jj rebase` and `jj new`
allows the user to do e.g. `jj rebase --allow-large-revsets -b
main.. -d main` to rebase all commits that are not in main onto
main. The reason we don't allow these revsets to resolve to multiple
commits by default is that we think users might specify multiple
commits by mistake. That's probably not much of a problem with `jj
rebase -b` (maybe we should always allow that to resolve to multiple
commits), but the user might want to know if `jj rebase -d @-`
resolves to multiple commits.
One problem with having a flag to allow multiple commits is that it
needs to be added to every command where we want to allow multiple
commits but default to one. Also, it should probably apply to each
revset argument those commands take. For example, even if the user
meant `-b main..` to resolve to multiple commits, they might not have
meant `-d main` to resolve to multiple commits (which it will in case
of a conflicted branch), so we might want separate
`--allow-large-revsets-in-destination` and
`--allow-large-revsets-in-source`, which gets quite cumbersome. It
seems better to have some syntax in the individual revsets for saying
that multiple commits are allowed.
One proposal I had was to use a `multiple()` revset function which
would have no effect in general but would be used as a marker if used
at the top level (e.g. `jj rebase -d 'multiple(@-)'`). After some
discussion on the PR adding that function (#1911), it seems that the
consensus is to instead use a prefix like `many:` or `all:`. That
avoids the problem with having a function that has no effect unless
it's used at the top level (`jj rebase -d 'multiple(x)|y'` would have
no effect).
Since we already have the `:` operator for DAG ranges, we need to
change it to make room for `many:`/`all:` syntax. This commit starts
that by allowing both `:` and `::`.
I have tried to update the documentation in this commit to either
mention both forms, or just the new and preferred `::` form. However,
it's useless to search for `:` in Rust code, so I'm sure I've missed
many instances. We'll have to address those as we notice them. I'll
let most tests use `:` until we deprecate it or delete it.
The `git.fetch` and `git.push` keys can be used in the configuration file
for the default to use in `jj git fetch` and `jj git push` operations.
By defaut, "origin" is used in both cases.
