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 :)
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.
Still UserSettings is cloned to WorkspaceCommandHelper, but I think this is
slightly better since CommandHelper and WorkspaceCommandHelper are scoped
based on call stack. Perhaps, UserSettings can be shared by Arc or immutable
reference.
This prepares for migration from ui.settings() to command.settings(). We could
instead add workspace_command.settings(), but I'm not sure which would be less
bad. Anyway, these functions live in command layer, so taking CommandHelper
makes sense.
I'm going to remove owned UserSettings from Ui so that UserSettings can be
instantiated after both user and repo configs are loaded. ui.cwd() belongs
to the same category (random environment stuff), and Ui doesn't depend on it,
so let's remove it first from Ui.
I'm not pretty sure if CommandHelper and WorkspaceCommandHelper should be
a permanent home for cwd and settings, but it works for now as CommandHelper
is immutable.
This and the subsequent patches prepare for the removal of ui.settings().
Ui will be a consumer of UserSettings (or config::Config) to make it clear
that Ui can be constructed before UserSettings is fully set up.
When you're done with the `CommitBuilder`, you're going to have to
call `write_to_repo()`, passing it a mutable `MutableRepo`
reference. It's a bit simpler to pass that reference when we create
the `CommitBuilder` instead, so that's what this patch does.
A drawback of passing in the mutable reference when we create the
builder is that we can't have multiple unfinished `CommitBuilder`
instance live at the same time. We don't have any such use cases yet,
and it's not hard to work around them, so I think this change is worth
it.
The divergent label is most relevant when the user is about to
refer to a commit by its change id.
It's also good to put it far from the `conflicts` label, to
reduce confusion between very different concepts that have
similar names.
Finally, I think it is a feature rather than a bug that the
`divergent` label now upsets the alignment of different lines
of `jj log`.
Since CR+LF vs LF things shouldn't matter in commit description, it's probably
better to normalize newline characters.
In Mercurial, ui.edit() and changelog.stripdesc() handle line normalization,
and trailing newlines are stripped. In Git, cleanup_message() handles that,
and the last newline is added after stripping trailing newlines.
Otherwise the description set by -m would differ from the one set by editor.
This fixes test_describe() which says "make no changes", but previously "\n"
would be added by the second "jj describe".
As you can see, almost all hashes change in CLI tests. This means in-flight
PRs will need to be rebased to update insta snapshots.
Description text could be normalized by CommitBuilder, but the caller would
have to normalize it beforehand to compare with the current description, so
we would need an explicit function anyway. Another idea is to add a newtype
that represents a normalized description, and make CommitBuilder require it.
Commit::description() will return &Description in place of &str to ensure
that commit.description() == raw_str wouldn't compile.
Git CLI provides --cleanup=<mode> option to switch normalization rules, but
I don't think we'll need such feature.
The next commit will introduce a newtype for -m/--message argument which
can be converted Into<String>.
Since CommitBuilder is a thin wrapper, code bloat caused by generic parameters
wouldn't matter. I have another set of commits that makes all builder methods
accept Into/IntoIterator, which will remove some of .clone() calls from tests.
I ran an upgraded Clippy on the codebase. All the changes seem to be
about using variables directly in format strings instead of passing
them as separate arguments.
"jj log -p --summary" now shows summary and color-words diff, like
"hg log -p --stat".
Handling of "-p" is tricky. I first considered "-p" would turn on the default
diff output, but I found it would be confusing if "jj log -p --git" showed
both color-words and git diffs. So the default format is inserted only if
no --git nor --color-words is explicitly specified.
This allows us to generate diff in different formats. There are various ways
to achieve that:
a. build TreeDiffIterator for each format (this patch)
b. make TreeDiffIterator clonable
c. collect TreeDiffIterator and reuse the resulting vec
(a) and (b) are practically the same. (c) would be more efficient if building
and iterating TreeDiffIterator were expensive, but I don't think it is because
Tree is cached by Store. If we add $GIT_EXTERNAL_DIFF-like feature, we'll
probably need Tree objects to snapshot them to /tmp. So I chose (a).
