I put this outside of the check for whether the tree changed because I
think it could be easy to miss the warning on the first snapshot, so
it's helpful if it prints the warning every time.
Currently, checking out a commit with conflicts in a colocated workspace
causes many editors to show all existing files as added since they
aren't present in the Git HEAD commit. Using the tree of the first side
of the commit as a base tree and then adding the '.jjconflict-*' trees
on top of it would cause any files identical to the first tree to show
as unchanged, matching Git's conflict behavior.
One potential downside to this change is that it becomes harder for a
user to notice if they incorrectly check out a conflicted commit using
`git switch`, since previously all of their files would've disappeared
so it would be more difficult to ignore. However, I think this could be
solved a different way, such as by adding a warning when snapshotting if
'.jjconflict' files are detected. Keeping the files from the first
tree also has the benefit that '.gitignore' files will still be present,
meaning that when a user does `jj abandon` to recover, it won't delete
their ignored files.
Using 'JJ-CONFLICT-README' as the name for the readme file instead of
'README' makes it more clear that this file is related to the
'.jjconflict-*' trees, since now the repo's actual README file might be
present as well in the tree.
Commands `jj log`, `jj evolog`, and `jj op log` automatically added a
terminating newline when the expanded template did not include one in graph
mode. No-graph mode did not do this, so the expanded template could combine with
any following content (diff, op changes, etc) in confusing or problematic ways.
Instead of trying to compensate in all cases, remove the auto-fixups. Users
should confirm their custom templates still expand correctly for their needs.
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.
Several commands accept both positional arguments and a `-r` flag for
specifying revisions. The `-r` flag exists for consistency with other
commands, but was previously hidden from help output.
Instead of unhiding `-r` (which would clutter the Options section),
document the aliasing by adding `[aliases: -r]` to the positional
argument's help text. This makes the relationship discoverable while
keeping the help output clean.
Commands updated: abandon, describe, duplicate, edit, metaedit, new, show
Fixes#8104
The help text for `jj split` was confusing about what happens to
"selected" vs "remaining" changes, especially with the `-o/-A/-B` flags.
This change:
- Adds ASCII diagrams showing the commit graph transformations for
default split, --parallel, and -o/-A/-B modes
- Clarifies that by default, selected changes stay in the original
commit while remaining changes go to a new child
- Explains that with -o/-A/-B, selected changes are extracted to a
new commit at the destination while remaining changes stay in place
- Improves the --message flag description to clarify it applies to
the first commit (containing selected changes)
- Adds explanatory text to the -o, -A, and -B flag descriptions
This is pretty low level, but we can at least know which extras table files are
active. The --key-size parameter doesn't matter so long as it is smaller than
the actual key size, but we might add sanity check later.
The 'gerrit upload' cli command is meant to support uploading commits
that have an explicit "Change-Id: ..." footer, and those that don't. In
the latter case, a temporary copy of the commit being uploaded will be
created, with the Change-Id set based on the jj change id.
Prior to this commit, there was a bug in this implementation when a
chain of commits contained some with Change-Id footers and some without.
Say we have commits a->b->c, where b has no Change-Id footer but c does
(this case is what's now tested in the test_gerrit_upload_local case).
The old logic would:
- create a new version of b (let's call it b*), with a CommitId footer,
and populate the 'old_to_new' map with 'b -> b*'
- not create a new version of c, and populate the 'old_to_new' map with
'c -> c'
- push the 'new' version of c, which is c itself. However, c has b as a
parent, not b*, so this fails to send to gerrit because b has no
Commit-Id footer!
After this commit, we create a new temporary commit if either the
description is changed (as before), or if any parents are different from
the original commit's parents. This does not change the behavior for
either the all-explicit or all-implicit ChangeId cases, but fixes the
behavior in this mixed case.
The 'gerrit upload' command has logic to handle commits with the
"Change-Id" explicitly set within the commit message, and commits
without the Change-Id explicitly set. This commit adds a test for the
behavior when all commits have the Change-Id explicitly set.
Also fix typo in existing test comment
It's usually going to be easier for a user to run the same command again
but with a change offset appended, so I think these are more helpful
than commit IDs.
I'm going to add a way to select a specific commit from the set of
commits with a given change ID. We could sort these by committer
timestamp or something else, but index position is convenient because it
doesn't require reading the commits. The exact order isn't too
important, but giving newer commits lower offset numbers is nice because
newer commits are used more frequently.
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.
When using `--interactive` or path arguments, it wasn't clear from the
help text what happens to the changes that aren't selected. This adds
an explanation to the main command documentation and updates the flag
and argument descriptions to use "current commit" instead.
Fixes#6666
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.
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.
