Commit graph

23 commits

Author SHA1 Message Date
Ilya Grigoriev
0e2579ee6a Switch graph node to use for commit instead of
This follows up on 5c703aeb03.

The only reason for this change is that, subjectively, the result looks better to me. I'm not sure why, but I couldn't get used to the old symbol in spite of its seeming reasonableness. It felt really bold and heavy.

If people agree, we can wait until we need to update the screenshots for some other reason before merging this. Sorry I didn't figure this out while the discussion about the referenced commit was going on.

I'm not 100% certain how many fonts support each symbol. Please try it out and let me know if it doesn't work for you.

Compare after:

![image](https://user-images.githubusercontent.com/4123047/229251383-563b889d-7233-42e2-a3c5-bf9368a4d1fd.png)

and before:

![image](https://user-images.githubusercontent.com/4123047/229251695-7fd0ff2c-2832-4262-ade5-5120288cccdf.png)
2023-04-02 23:15:37 -07:00
Martin von Zweigbergk
5c703aeb03 cli: replace o as graph node by when using unicode graph
@joyously found `o` confusing because it's a valid change id prefix. I
don't have much preference, but `●` seems fine. The "ascii",
"ascii-large", and "legacy" graph styles still use "o".

I didn't change `@` since it seems useful to have that match the
symbol used on the CLI. I don't think we want to have users do
something like `jj co ◎-`.
2023-03-12 23:21:05 -07:00
Martin von Zweigbergk
f70e6987b5 conflicts: preserve order of adds in materialized conflict
We write conflict to the working copy by materializing them as
conflict markers in a file. When the file has been modified (or just
the mtime has changed), we parse the markers to reconstruct the
conflict. For example, let's say we see this conflict marker:

```
<<<<<<<
+++++++
b
%%%%%%%
-a
+c
>>>>>>>
```

Then we will create a hunk with ["a"] as removed and ["b", "c"] as
added.

Now, since commit b84be06c08, when we materialize conflicts, we
minimize the diff part of the marker (the `%%%%%%%` part). The problem
is that that minimization may result in a different order of the
positive conflict terms. That's particularly bad because we do the
minimization per hunk, so we can end up reconstructing an input that
never existed.

This commit fixes the bug by only considering the next add and the one
after that, and emitting either only the first with `%%%%%%%`, or both
of them, with the first one in `++++++++` and the second one in
`%%%%%%%`.

Note that the recent fix to add context to modify/delete conflicts
means that when we parse modified such conflicts, we'll always
consider them resolved, since the expected adds/removes we pass will
not match what's actually in the file. That doesn't seem so bad, and
it's not obvious what the fix should be, so I'll leave that for later.
2023-02-18 22:01:25 -08:00
Martin von Zweigbergk
e48ace56d1 conflicts: replace missing files by empty in materialized conflict
When we materialize modify/delete conflicts, we currently don't
include any context lines. That's because modify/delete conflicts have
only two sides, so there's no common base to compare to. Hunks that
are unchanged on the "modify" side are therefore not considered
conflicting, and since they they don't contribute new changes, they're
simply skipped (here:
3dfedf5814/lib/src/files.rs (L228-L230)).

It seems more useful to instead pretend that the missing side is an
empty file. That way we'll get a conflict in the entire file.

We can still decide later to make e.g. `jj resolve` prompt the user on
modify/delete conflicts just like `hg resolve` does (or maybe it
actually happens earlier there, I don't remember).

Closes #1244.
2023-02-17 22:19:04 -08:00
Martin von Zweigbergk
a67fbb6714 cli: switch default graph style to be Sapling's curved style
We seem to quite unanimously prefer this style, so let's make the
default.
2023-02-12 07:23:29 -08:00
Martin von Zweigbergk
6ae671960c formatter: don't write escape codes until we write text
We often end up writing escape codes for one style and then
immediately after, we write escape codes for another style. That seems
harmless, but it's a little ugly. More importantly, it prepares for
not emitting any escapes for turning off attributes at the end of
formatted contents across multiple lines (see next commit).
2023-01-13 21:47:50 -08:00
Martin von Zweigbergk
5cf2b6615a formatter: use crossterm for colors
Let's use `crossterm` to make `ColorFormatter` a little more readable,
and maybe also more portable.

This uses the `SetForegroundColor()` function, which uses the escapes
for 256-color support (code 38) instead of the 8-color escapes (codes
30-37) combined with bold/bright (code 1) we were using before. IIUC,
most terminals support the 16 base colors when using the 256-color
escape even if they don't support all the 256 colors. It seems like an
improvement to use actual color codes for the bright colors too,
instead of assuming that terminals render bold as bright (even though
most terminals do).

Before this commit, we relied on ANSI escape 1 - which is specified to
make the font bold - to make the color brighter. That's why we call
the colors "bright blue" etc. When we switch from using code 30-37 to
using 38 to let our color config just control the color (not using
escape1), we therefore lose the bold font on many terminals (at least
in iTerm2 and in the terminal application on my Debian work
computer). As a workaround, I made us still use escape 1 when the
bright colors are used. I'll make boldness a separately configurable
attribute soon. Then we'll be able to remove this hack.

With the switch to `crossterm`, we also reset just the foreground
color (code 39) instead of resetting all attributes (code 0). That
also seems like an improvement, probably making it easier for us to
later support different background colors, underlining, etc.
2023-01-13 21:47:50 -08:00
Ilya Grigoriev
6b064ef54e run_merge_tool, edit_diff: Print command args with -v instead of errors 2023-01-12 23:07:59 -08:00
Ilya Grigoriev
9a3329ee25 jj resolve --list: make output aligned
If all file names are short enough, this will align the conflict
description at 4 spaces past the longest file name, as follows.

```
src/templater.rs            2-sided conflict
src/templater_parsers.rs    2-sided conflict
```

If there is a long file name, conflict descriptions will either start
or column 35 or one space from a file name, whichever is later.

Previously, a single tab was used to separate file name from conflict
description. This didn't look as nice as I hoped when multiple files
are involved. I also don't think `jj` generally uses tabs in output.
The tab uncovered a bug in a watcher program I was using.
2023-01-11 23:29:53 -08:00
Ilya Grigoriev
5b1b35cbfe Update test to prepare for next commit 2023-01-11 23:29:53 -08:00
Ilya Grigoriev
fc9795e902 jj resolve --list: make output colorful
The description is usually in yellow, which looks nice and neutral. If the
conflict has more than 2 sides or has special files, that's marked in red.
2023-01-07 15:29:19 -08:00
Ilya Grigoriev
89de9aeae1 jj resolve --list: Replace separator with \t
The `:` was a bit noisy. With upcoming color support, it seems unnecessary.

This should also be a little better for any tools that want to parse the
output.

Finally, `insta` also seems to want to rewrite test snapshots to be shorter.
They seem equivalent.
2023-01-07 15:29:19 -08:00
Ilya Grigoriev
621293d7c6 jj resolve --list: Add descriptions of conflict complexity
The descriptions focus on adds, not the deletions. The deletions are used
to compute the number of deleted files that must be sides of the conflict.
2023-01-05 10:59:14 -08:00
Ilya Grigoriev
5ecac4fc44 jj resolve: List remaining conflicts (if any) on success
This can be prevented by the new `--quiet` option.
2023-01-04 21:48:33 -08:00
Ilya Grigoriev
b8ba78b996 Extract resolve_list from cmd_resolve, tests, minor refactoring
This is all in preparation for follow-up commit, which will change
some of the new tests. The extracted function will be further expanded
later.
2023-01-04 21:48:33 -08:00
Yuya Nishihara
5076622598 tests: use insta to test editor contents
It's tedious to update editor expectation manually. Let's dump the actual
content and test it after each command invocation.
2022-12-23 00:47:22 +09:00
Ilya Grigoriev
9e334de7d6 Remove insta::assert_snapshot that causes a failure with insta 1.22 2022-12-05 22:29:05 -08:00
Ilya Grigoriev
e9952bcf76 Minimal version of resolve --list
Simply lists conflicted files
2022-12-04 22:58:12 -08:00
Ilya Grigoriev
ea1395ad95 Make optional the path argument to resolve, allow partial paths
Also allows several paths to be specified. By default, `jj resolve`
will find the first conflict that matches provided paths (if any)
and try to resolve it.
2022-12-04 22:39:45 -08:00
Ilya Grigoriev
b58be8d7a4 Mention path in message for ConflictResolveError::NotNormalFilesError. 2022-12-04 22:39:45 -08:00
Martin von Zweigbergk
48c44344bf cli: make jj status not just care about the first parent
It seems like I forgot to update the `jj status` output when I decided
(years ago?) that the changes in a commit should always be compared to
the auto-merged parents. I was very confused before I realized that
`jj status` was showing the diff summary against the first parent. I
suppose the fact that `jj status` lists only one parent should have
been a hint. Thanks to ilyagr@ for finding this odd behavior. This
patch fixes it by making the command list all parents, and changes the
diff summary to be against the auto-merged parents.
2022-12-04 22:29:12 -08:00
Ilya Grigoriev
d6c1b0bc9c jj resolve: option to parse conflict markers + tests
If this new option is not specified, we start with empty output
file and trust the merge tool did a complete merge no matter
what the file contains.

Includes tests.
2022-12-03 15:12:40 -08:00
Ilya Grigoriev
3e86baa7f1 Test basic jj resolve functionality 2022-12-03 15:12:40 -08:00