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.
Deprecation warnings will be emitted for default "substring:" patterns. This
change will suppress them. Since "glob:" will be the new default, I made these
tests use "glob:" when both "exact:" and "glob:" work.
Tests for the revset filter functions aren't updated.
There were some concerns that `touch` only makes sense if you're
familiar with the Unix `touch` command. I think that's a fair
concern. I did not hear any objections to renaming the command. If
we're going to do it, we should do it now, so it doesn't ever get
released under the old name.
For example, with a commit tree like this one:
@ kkrvspxk (empty) (no description set)
○ lpllnppl file4
│ A file4
○ xynqvmyt file3
│ A file3
○ wkrztqwl file2
│ A file2
○ mzuowqnz file1
│ A file1
♦ zzzzzzzz root()
we can jj squash -f x:: -d m to squash xynqvmyt and all its descendant
as a new commit onto mzuowqnz.
@ youptqqn (empty) (no description set)
○ wkrztqwl file2
│ A file2
│ ○ vsonsouy file3 file4
├─╯ A file3
│ A file4
○ mzuowqnz file1
│ A file1
♦ zzzzzzzz root()
On the implementation side, I've chosen to prepare the destination
commit before hand, and keep the squash algorithm mostly unmodified.
Since divergent/conflicted symbols no longer resolve to multiple revisions, it's
less scary to allow "large" revsets than before.
The config doc is removed because it's largely duplicated from the revsets doc,
and the config key will be removed.
#6016
closes#6587
Given a commit history like this:
○ ccc
○ bbb
◆ aaa
Parallelize *should* be able to create this:
○ ccc
│ ○ bbb
├─╯
│ ◆ aaa
├─╯
This is fine because `aaa` will not be rewritten --- its children will,
but neither `aaa`'s parents nor author information needs to be changed.
However, the current implementation checks _all_ commits in the
target set for rewritability, instead of only the commits that will
be rewritten.
This commit changes that. Now, only the commits whose parents *will*
change are checked for rewritability.
the feature reused as much as possible of the `jj rebase` code, with
minimum modifications, in order to avoid reimplementing or complexifying
the rebase code.
It leads to some cases where some commits may be rewritten twice.
For example:
❯ jj -s
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file1
│ A file2
◆ zzzzzzzz root()
❯ jj split -r u -A m -m file1 file1
Rebased 3 descendant commits
First part: ulpvupsv aaf064bc file1
Second part: uttlrpzl 0d4358c2 file1&2
Working copy (@) now at: ylrkuwto 60d905c5 (empty) (no description set)
Parent commit (@-) : qsorlqym 8cfbe2d8 file4
❯ jj -s
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ ulpvupsv file1
│ A file1
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file2
◆ zzzzzzzz root()
There is an intermediate state created as
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file2
○ ulpvupsv file1
│ A file1
◆ zzzzzzzz root()
where the commits in `uttlrpzl::` have been rewritten, then `ulpvupsv`
is moved, effectively rewriting the commits in `ulpvupsv::`.
The number of user visible rewritten commits is accurately reported.
`jj split --parallel` is still done as a special case: implementing
it with the rebase code would put the first commits on the right
branch.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
The output of `jj unsign` is based on that of `jj abandon`.
We output warnings when unsigning commits, which are not authored by the
user. This is encouraging to use `jj undo`, in case one unintentionally
drops signatures of others.
---
Co-authored-by: julienvincent <m@julienvincent.io>
Co-authored-by: necauqua <him@necauq.ua>
We always sign commits. This means commits, which are already signed,
will be resigned. While this is cumbersome for people using hardware
devices for signatures, we cannot reliably check if a commit is already
signed at the moment (see https://github.com/jj-vcs/jj/issues/5786).
We output warnings when signing commits, which are not authored by the
user. This is encouraging to use `jj undo`, in case one unintentionally
signs commits of others.
The output of `jj sign` is based on that of `jj abandon`.
---
Co-authored-by: julienvincent <m@julienvincent.io>
Co-authored-by: necauqua <him@necauq.ua>
There have been a number of users confused about why
their commits are immutable, or what to do about it, ex.
[https://github.com/jj-vcs/jj/discussions/5659].
Separately, I feel that the cli is too quick to suggest
`--ignore-immutable`, without context of the consequences. A new user
could see that the command is failing, see a helpful hint to make it not
fail, apply it and move on. This has wildly different consequences, from
`jj squash --into someone_elses_branch@origin` rewriting a single commit,
to `jj edit 'root()+'` rewriting your entire history.
This commit changes the immutable hint by doing the following:
* Adds a short description of what immutable commits are used for, and a
link to the relevant docs, to the hint message.
* Shows the number of immutable commits that would be rewritten if
the operation had succeeded.
* Removes the suggestion to use `--ignore-immutable`.
With this change a warning is shown if the user does not explicitly specify the target revision, but the behavior is unchanged (it still defaults to the working copy).
In the future the warning will be turned into an error. In other words, it will be required to specify target revision.
The bulk of the changes here are to prepare tests for the upcoming change, to make the transition easier.
For additional details please see:
* https://github.com/jj-vcs/jj/issues/5374
* https://github.com/jj-vcs/jj/discussions/5363
I hope we'll have support for copies and renames in not too long. It's
good to have as many versions before that as possible without support
for `jj move`, in case we want to later use that to record a moved
file (maybe as an alias for `jj file move`).
The destination commits are selected based on annotation, which I think is
basically the same as "hg absorb" (except for handling of consecutive hunks.)
However, we don't compute a full interleaved delta right now, and the hunks are
merged in the same way as "jj squash". This means absorbed hunks might produce
conflicts if no context lines exist. Still I think this is more intuitive than
selecting destination commits based on patch commutativity.
I've left inline comments to the tests where behavior is different from "hg
absorb", but these aren't exhaustively checked.
Closes#170
Previously, attempting to modify an immutable commit only showed the
ID of the commit being modified, which wasn't very helpful when trying
to figure out which immutable commit is being modified at a quick
glance.
This commit prints the commit summary as a hint to make it simpler for
the user to see what the immutable commit is without having to run
`jj show <commit-id>`.
The id.shortest() template prints a warning and falls back to repo-global
resolution. This seems better than erroring out. There are a few edge cases
in which the short-prefixes resolution can fail unexpectedly. For example, the
trunk() revision might not exist in operations before "jj git clone".
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.
For the same reason as the previous commit.
Created and moved stats are printed separately because it's unusual to do both
within one "branch set" invocation.
It's common to create empty working-copy commits while using jj, and
currently the author timestamp for a commit is only set when it is first
created. If you create an empty commit, then don't work on a repo for a
few days, and then start working on a new feature without abandoning the
working-copy commit, the author timestamp will remain as the time the
commit was created rather than being updated to the time that work began
or finished.
This commit changes the behavior so that discardable commits (empty
commits with no description) by the current user have their author
timestamps reset when they are rewritten, meaning that the author
timestamp will become finalized whenever a commit is given a description
or becomes non-empty.
Still alias function shadows builtin function (of any arity) by name. This
allows to detect argument error as such, but might be a bit inconvenient if
user wants to overload heads() for example. If needed, maybe we can add some
config/revset syntax to import builtin function to alias namespace.
The functions table is keyed by name, not by (name, arity) pair. That's mainly
because std collections require keys to be Borrow, and a pair of borrowed
values is incompatible with owned pair. Another reason is it makes easy to look
up overloads by name.
Alias overloading could also be achieved by adding default parameters, but that
will complicate the implementation a bit more, and can't prevent shadowing of
0-ary immutable_heads().
Closes#2966
When you use e.g. `git switch` to check out a conflicted commit,
you're going to end up with the `.jjconflicts-*` directories in your
working copy. It's probably not obvious what those mean. This patch
adds a README file to the root tree to try to explain to users what's
going on and how to recover.
The authoritative information about conflicts is stored in the
`jj:trees` commit header. The contents of conflicted commits is only
used for preventing GC. We can therefore add contents to the tree
without much consequence.
Parallelize revisions by making them siblings
Running `jj parallelize 1::2` will transform the history like this:
```text
3
| 3
2 / \
| -> 1 2
1 \ /
| 0
0
```
Each of the target revisions is rebased onto the parents of the root(s) of
the target revset (not to be confused with the repo root). The children of
the head(s) of the target revset are rebased onto the target revisions.
The target revset is the union of the REVISIONS arguments.
The target revset being parallelized must satisfy several conditions,
otherwise the command will fail.
1. The heads of the target revset must not have different children.
2. The roots of the target revset must not have different parents.
3. The parents of all target revisions except the roots must also be
parallelized. This means that the target revisions must be connected.
