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.
This paves the way to deprecate the `--allow-new` flag on `jj git push`
without adding lots of deprecation warnings to test output snapshots.
The behavior of some tests is slightly changed, because
auto-track-bookmarks tracks all bookmarks at creation time, not when
they're about to be pushed. Where appropriate, I tracked bookmarks
manually instead of via the auto-track config.
This paves the way to deprecate `git.auto-local-bookmark` without
adding lots of deprecation warnings to test output snapshots.
The behavior of some tests is slightly changed, because
auto-track-bookmarks also tracks bookmarks that were created locally.
I think it just shows up in output snapshots as absent-tracked
bookmarks, without affecting what the test is about.
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
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
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.
An existing "push-*" bookmark should usually be in position. If it wasn't
because of e.g split, I think the user should be aware of that and take an
explicit action.
Follows up on https://github.com/jj-vcs/jj/pull/5698 and
https://github.com/jj-vcs/jj/pull/6236.
The behavior of `--named` in corner cases differs. This wasn't detected
in #5698 because of a bug in the test that was fixed in #6236. This
commit better illustrates the more important case where the behavior is
the same, and the less important case where it differs.
It's deprecated since 1aad250420 "Shorten the git push branch when possible
using the short change ID hash" (2023-01-12). I don't think we need the
fallback. I also removed the check for ambiguous prefixes as I believe it
wouldn't practically matter. If needed, we can add a check for existing bookmark
pointing to different commit. We can also make it templated with default
"'push-' ++ change_id.shortest(12)".
We've been finding that a lot of bug reports on `jj git push` come from
sub-standard error reporting on the reasons the failure happens.
It can come from a number of places:
- hook failure
- remote branch protection
- git config
This commit forwards the reason as explained by the ouptut of git push
to help users figure out what is happening.
We need to report more complicated errors on push.
Firstly, we can have a mix of unexpected ref locations and remote
rejections. We should report both at the same time.
Second, git gives us a reason for why a push failed.
For this to work, it's relevant to refactor the current error reporting
path to allow us to inject this information.
The git remote sideband adds a dummy suffix of 8 spaces to attempt to clear
any leftover data. This is done to help with cases where the line is
rewritten.
However, a common option in a lot of editors removes trailing whitespace.
This means that anyone with that option that opens this file would make the
following snapshot fail. Using the insta filter here normalizes the
output.
When we push a ref to a git remote, we use --force-with-lease
Our understanding was that this could fail iff the expected location of
the ref on the remote was not that of the local tracking ref
However, if the ref is from a protected branch (e.g., main) it will be
rejected by the remote for a different reason.
This commit solves this, by detecting this difference.
