Now that we can put the "from" and "to" sides on separate lines, we can
use the normal "(no terminating newline)" comment on each side
separately. This should also be more clear, since previously the
"(no terminating newline)" comment could possibly be confused for
"(removes terminating newline)".
Before:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "commit A" (no terminating newline)
grapefruit
%%%%%%% diff from: vpxusssl 38d49363 "merge base"
\\\\\\\ to: ysrnknol 7a20f389 "commit B" (adds terminating newline)
-grape
+grape
>>>>>>> conflict 1 of 1 ends
```
After:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "commit A" (no terminating newline)
grapefruit
%%%%%%% diff from: vpxusssl 38d49363 "merge base" (no terminating newline)
\\\\\\\ to: ysrnknol 7a20f389 "commit B"
-grape
+grape
>>>>>>> conflict 1 of 1 ends
```
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.
An example with parents `rtsqusxu` and `ysrnknol`:
```
<<<<<<< conflict 1 of 1
%%%%%%% diff from: vpxusssl 38d49363 "description of base"
\\\\\\\ to: rtsqusxu 2768b0b9 "description of left"
-base
+left
+++++++ ysrnknol 7a20f389 "description of right"
right
>>>>>>> conflict 1 of 1 ends
```
Conflict labels will generally start with lowercase change IDs, so
making all of the text lowercase makes it more consistent. I also
removed the "contents of" text, since conflict labels will already be
long enough, and this text doesn't add anything. Similarly, I removed
the "(conflict 1 of 1)" note from the Git conflict markers since Git
doesn't include this information, and including it would result in extra
long lines once we add conflict labels.
Rename parameter type `String` to `StringLiteral` where methods require
a literal string known at parse time rather than a dynamic expression.
This makes the documentation faithful to the underlying code, which uses
`expect_string_literal()` and reports "Expected string literal" errors.
Add a new `StringLiteral` type section explaining the distinction.
Fixes#7068
This cross-reference was added in 998727266c (March 2023) when
ListTemplate was first documented. At that time, List only had two
methods: .join() and .map(). The reference made some sense since
ListTemplate was the result type of .map() and shared the .join()
method.
However, List has since grown significantly with .len(), .filter(),
.any(), .all(), and Boolean conversion - none of which ListTemplate
supports. ListTemplate still only has .join(). This makes the
cross-reference misleading, as it implies a compatibility that
doesn't exist (unlike List<Trailer> which truly extends List).
Fixes#7951
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
Handling of dim and bold is a bit complicated because these two attributes
cannot be unset individually. I think NormalIntensity will work for resetting
both bold and dim, but I don't have expertise on terminal implementations. So
this patch applies the same workaround as bold to dim.
Fixes#1941
I'm including this in the contributing.md rather than in docs/technical because
it's not particularly long, and there's already some information there.
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.
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
Delete the dead reference to bwb's cultivate which no longer is actively worked on since
in the mean time ersc was founded. Also sort the links in the doc.
The primary benefit of this change is that it splits
"lines_added()" and "lines_removed()" into separate fields,
which will be useful for tools.
Many tools use "status()", "lines_added()", "lines_removed()",
"source()" and "target()" to show useful information about
every file modified in a commit.
The existing diff stats summary shows only the combined
number of lines modified, along with a "percentage" representation
of line additions vs. deletions. This is lossy and not
useful for tools, since it is impossible to arrive at
the exact number of lines added and deleted.
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.
Glob patterns will be enabled by default globally. Since this will be a big
breaking change in revsets, this patch adds a config knob to turn the new
default on/off.
These commands are easy ones. The other commands error out if one of the
patterns doesn't match anything. I'll make them warn only exact patterns instead
to keep the implementation simple. I'll also add warnings to these list
commands.
