It's common to write a formatted error/warning message, but we can't use
writeln!() with the current ui.write_*() API, and sometimes we forget to
add "\n" to the message. With this wrapper, ui.write_error("message\n")
will be writeln!(ui.error(), "message"), and trivial formatter.with_label()
call can be replaced with write!(formatter.labeled(...), ...).
This can be disabled with the new `--quiet` option.
Printing every commit would give the user all the information of how to undo
this or where to `jj restore` from if they realize they need to after the
abandon.
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.
If a workspace path is explicitly specified, it must point to the exact
workspace directory. This is the same behavior as 'hg -R'. OTOH, 'git -C'
is the option to chdir, so it makes sense to search .git from that directory.
This also fixes 'jj -R ../..' which would previously look up '../..', '..',
'.', ...
I don't think Workspace::load() should be permissive in that regard.
WorkspaceLoader could provide such function, but I feel it's more like
CLI business. CLI can also look for parent '.git' directory to suggest
'jj init --git-repo=..' if needed.
The divergent changes are marked with ?? (I found a single ? a bit easy to
overlook), and this should be consistent.
Ideally, the conflicted branches would also be red, but this takes a bit
larger changes to `templater.rs`: another `Property` as well as changes to
https://github.com/martinvonz/jj/blob/7f9a0a28/src/template_parser.rs#L385-L395
This allows us to load workspace by using &Result<T, CommandError>. Even
though load_workspace() wouldn't be called more than once, consuming self
there is annoying.
I don't see a good reason to let e.g. "added diff" to match added text
inside a diff when we already allow "diff added" for that. Allowing
both means that we have to decide which should take precedence. With
the recent change to add labels for methods, we no longer depend on it
for the "timestamp author" case ("author timestamp" now
matches). Thanks to @yuja for noticing that dependency.
We now already have the "timestamp" label from the auto-labeling of
method calls.
Without the use of the "email" label in the previous commit, we would
now emit an unnecessary color code when the "author" label is added
but before the "timestamp" is added. So that patch wasn't just about
simplifiying the config :)
I'm going to make `parse_method_chain` also return a list of labels to
add, so we can make e.g. `author.timestamp()` automatically get
labeled with both "author" and "timestamp".
It's clearly the parser's job to split labels in a string provided by
the user. This patch moves the splitting we were doing in
`LabelTemplate` and `DynamicLabelTemplate` to the parser. In the
former case, the string isn't even provided by the user and it doesn't
contain whitespace, we can drop the splitting altogether.
An important part of the `jj log` output is the commit template. I
suspect we'll have many more tests for that, so let's move it to a
separate file. The main `test_log_command.rs` can focus on which
commits to display.
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.
This will match `jj`'s behavior of being unable to resolve such conflicts or to
show readable diffs for them, in the pre-#978 state.
This is a fixup of 621293d7c6.
Since per-repo config may contain CLI settings, it must be visible to CLI.
Therefore, UserSettings::with_repo() -> RepoSettings isn't used, and its
implementation is nullified by this commit.
#616
It's unclear whether parse_args() or its caller should update LayeredConfigs.
--config-toml is processed by callee to apply --color early. -R/--repository
will be processed by caller since it will instantiate WorkspaceLoader.
Maybe --config-toml can be removed from EarlyArgs, and handle_early_args()
just updates ui state based on --color argument?
Thinking of config precedence, we'll probably need to store "base" (default +
env_base + user) config and "override" (env_overrides + --config-toml) config
separately to support repo config. Suppose env_overrides() is a temporary
value, it's better to override any file-derived values with $JJ_ env.
