Color-words diffs use formatter labels to distinguish removed and
added tokens. When color is disabled, those labels are invisible,
so inline word changes can collapse into unreadable text when
stdout is not a TTY.
Render color-words hunks as separate before and after lines
whenever the formatter cannot emit color. This keeps the default
diff format stable while making piped or redirected output
readable.
Color-words tests that rely on inline display force color output
because inlining is only triggered when color is available, ANSI
sequences are stripped before snapshotting to keep the snapshots
readable.
This does not make redirected diffs into git-format patches.
Users still need --git for patch exchange or tools that require
unified diff input.
Fixes#5894.
Related to #6972.
There are two reasons for this:
* It helps understanding why divergence happened to see which
workspace an operation was run from. For example, perhaps an agent
is running in another workspace and it's not obvious from the
operation log which commands it ran without seeing the workspace
name.
* We may want to check that e.g. `jj undo` is run from the same
workspace as the operation it's undoing. We may want to print a
warning otherwise, or maybe we want to skip over operations create
from other workspaces. I'm not sure what's best but having the
workspace recorded at least enables such features.
Mostly done with OpenCode and Claude Sonnet 4.6 with the following prompt,
and reviewed manually:
Replace the Result.unwrap with the ? operator in test functions.
While doing that, make sure to:
* Add TestResult as return type in the test functions where you replace
unwrap by the ? operator, and Ok(()) at the end.
* Do the replacement only in method with the `#[test]` decorator.
* Don't replace unwraps in closures.
* Don't replace Option.unwrap.
* Be careful to not change the insta snapshot references.
* Run the tests each time you're done with a file.
* Keep the unwraps that you can't replace with the ? operator.
Note that:
* You can identify all the Result.unwrap locations with this command:
cargo clippy --tests --message-format=short -- -W clippy::unwrap_used 2>&1 | grep / | grep Result | grep <filename>
* Begin with the file with the most Result.unwrap in them as shown by
this command:
cargo clippy --tests --message-format=short -- -W clippy::unwrap_used 2>&1 | grep Result | cut -d: -f1 | sort | uniq -c | sort -nr
* Some non test files have inline tests.
Before this PR:
❯ cargo clippy --tests --message-format=short -- -W clippy::unwrap_used 2>&1 | grep Result | wc -l
3973
After this PR:
❯ cargo clippy --tests --message-format=short -- -W clippy::unwrap_used 2>&1 | grep Result | wc -l
1064
Converts a git remote URL to an HTTPS web URL for opening in a browser.
Defaults to the "origin" remote. Returns an empty string if the remote
doesn't exist or the URL cannot be converted.
Resolves#7507
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.
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
This will help notice small hunks in inlined diff lines. Not all terminals would
support "dim" attribute, but I think that's okay since the diff output should be
readable with/without this change.
Closes#5140
While these two are stored in view objects, we intentionally ignore them when
undoing. This means that these fields don't have to be tracked by
view/operation. I think we can move them away to GitBackend-specific data.
We could provide git_head()/git_refs() that load data from GitBackend, but I
don't think these template/revset functions are useful. I've never used them
except for the git_head() template function, and its use case was to see whether
the repository is colocated or not.
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.
Since this is a test for template output of various bookmark states, it's better
to not rely on implicit configuration. Local bookmark "new-bookmark" wasn't
tracked before.
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.
Since we can now update tags internally, local and remote tags may be out of
sync in non-colocated Git repositories. "tags" template should indicate that.
Gerrit's web UI (like jj) recognizes unique ID prefixes, so a reference
like `I1234cdef` in a commit message or a review comment becomes a
hyperlink to the referenced change. Currently, every jj-produced change
begins with `I6a6a6964`, which makes that less useful. This moves the
fixed `6a6a6964` component to the end, so the prefix is unique.
Closes#7500.
The top-level `immutable` and `conflict` labels we add to commits in
the node templates are also useful in the text part. For example, we
may want to color change ids for immutable commits differently (we do
that at Google). I also added a `mutable` label, to make it easier to
define colors for mutable commits without having to define the color
for all commits and then overriding it for immutable commits.
The operation timestamp is often very close to the committer timestamp, so I
don't think it's useful in evolog. I also removed "root()" as it wouldn't be
useful either, and the root operation should have no evolved commits.
I think this can be useful in CLI tests. I noticed there are lots of "jj file
list" calls in https://github.com/jj-vcs/jj/pull/6141 which could be combined
with "jj log" outputs.
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
Since operation templates have "operation" label, commit templates should have
"commit" for consistency.
The [colors] table is not updated to use the "commit" prefix. There are some
non-template outputs which use unqualified "bookmark"/"tag"/"git_ref" labels.
That's also a reason why "bookmark_list" template doesn't have a "bookmark"
context label yet. (We'll need to qualify the color definition as "commit
bookmark" so the whole bookmark list wouldn't be colorized as "bookmark".)
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.
namely Signed-off-by and Change-Id
`format_signed_off_by_trailer` will be formatted properly if the author
name is not set, but will contain the email placeholder if the author
email is not set, as I haven't found a way to make the template
generation fail.
`format_gerrit_change_id_trailer` is based on jj's change id, but it
needed to be padded to reach 40 characters. Zero-padding is kind of
boring so I've used `6a6a6964`, the hexadecimal representation of `jjid`
in ascii.
Because the trailer value runs up to the end of the line, they are
all terminated with a new line. This way it's also convenient to
define these trailers in the `commit_trailers` template:
[templates]
commit_trailers = '''
format_signed_off_by_trailer(self)
++ format_gerrit_change_id_trailer(self)
'''
With this template, a 'git format-patch' compatible
email message can be generated using something like:
jj show --git --template git_format_patch_email_headers <rev>
std::fs::rename() and symlink() aren't added to TestWorkDir. There are few
instances of rename(). work_dir.symlink() would be a bit unclear whether the
link content path is normalized, which usually shouldn't.
