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.
Running "cargo insta test --workspace", results in numerous warnings:
Snapshot test passes but the existing value is in a legacy format.
Please run `cargo insta test --force-update-snapshots` to update to
a newer format.
This commit is the result of running the suggested command.
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.
This follows Git's merge driver interface which makes this information
available using the `%P` variable. It is useful for merge drivers to
adapt their behaviour based on the type of file supplied.
This patch adds a `TreeValue::File::copy_id` field. The copy ids are
always empty for now. I preserved the copy id where it was easy to do
so, plus in a few non-trivial cases. In other places, however, I made
the code use a new copy id. I added a `CopyId::placeholder()`
function for creating a new copy id where we need one. We should
eventually fix all callers to either preserve an existing copy or to
generate a new one.
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.
As Martin suggested, "we should instead make it an error to try to resolve the
content-level conflict before resolving the executable-bit-level conflict. I
think we should do the same when merging copy records."
https://github.com/jj-vcs/jj/pull/6288#pullrequestreview-2751367755
try_materialize_file_conflict_value() and to_file_merge() shouldn't fail because
of exec bit changes. And error.to_string() shouldn't include trailing newline.
These merge tools didn't work properly on conflicted trees with more
than two sides since they didn't simplify the conflict before resolving.
The new implementation is more similar to how external merge tools are
executed, which should give a more consistent behavior.
I'm going to add "[EOF]" marker to test that command output is terminated by
newline char. This patch ensures that callers who expect a raw output string
would never be affected by any normalization passes.
Some common normalization functions are extracted as CommandOutputString
methods.
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
If many files are conflicted, it would be nice to be able to resolve all
conflicts at once without having to run `jj resolve` multiple times.
This is especially nice for merge tools which try to automatically
resolve conflicts without user input, but it is also good for regular
merge editors like VS Code.
This change makes the behavior of `jj resolve` more consistent with
other commands which accept filesets since it will use the entire
fileset instead of picking an arbitrary file from the fileset.
Since we don't support passing directories to merge tools yet, the
current implementation just calls the merge tool repeatedly in a loop
until every file is resolved, or until an error occurs. If an error
occurs after successfully resolving at least one file, the transaction
is committed with all of the successful changes before returning the
error. This means the user can just close the editor at any point to
cancel resolution on all remaining files.
Git supports passing the conflict marker length to merge drivers using
"%L". It would be useful if we also had a way to pass the marker length
to merge tools, since it would allow Git merge drivers to be used with
`jj resolve` in more cases. Without this variable, any merge tool that
parses or generates conflict markers could fail on files which require
conflict markers longer than 7 characters.
https://git-scm.com/docs/gitattributes#_defining_a_custom_merge_driver
Currently, `jj resolve` always sets the file to be non-executable
whenever a conflict is fully resolved. This is confusing, because it can
cause the executable bit to be lost even if every side agrees that the
file is executable.
