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.
UserSettings will be instantiated after both user and repo configs are
loaded. We might want to add a wrapper for CLI settings, but I have no idea
how that should be structured. Let's use bare config::Config until then.
Let's acknowledge everyone's contributions by replacing "Google LLC"
in the copyright header by "The Jujutsu Authors". If I understand
correctly, it won't have any legal effect, but maybe it still helps
reduce concerns from contributors (though I haven't heard any
concerns).
Google employees can read about Google's policy at
go/releasing/contributions#copyright.
There's a risk of forgetting to call `remove_label()` and I've wanted
to reduce that risk for a long time. I considered creating RAII
adapters that implement `Drop`, but I didn't like that that would
ignore errors (such as `BrokenPipe`) that can happen while emitting an
escape sequence in `remove_label()`. I would ideally have liked
Python's context managers here, but Rust doesn't have that. Instead,
we get to use closures. That works pretty well, except that we can't
return other errors than `io::Error` inside the closures. Even with
that limitation, we can use the new `with_label()` method in all but a
few cases.
We can't define the `with_label()` method directly in the trait
because `&mut self` is not a trait object, so we can't pass it on to
the closure (which expects a trait object). The solution is to use
`impl dyn Formatter` (thanks to @kupiakos for figuring that
out!). That unfortunately means that we can *only* call the function
on trait objects, so if `f` is a concrete formatter type
(e.g. `PlainTextFormatter`), then `f.with_label()` won't
compile. Since we only ever access the formatters as trait objects,
that's not really a problem, however.
Since the concrete Formatter type is hidden behind the Ui, there wouldn't
be many reasons to use dyn Write at the formatter layer. This allows us
to create a formatter against MutexGuard<Box<dyn Write>> without one more
Box<dyn Write> wrapper.
This should help to create a temporary ColorFormatter instantly.
A cached_colors table could also be shared across formatters, but doing that
would require some locking mechanism. Since commands like cmd_log/diff()
use a single formatter instance, I don't think shared mutable cache would be
needed for the moment.
It seems helpful to show in the log output which commit is checked out
in which workspace, so let's try that. I made it only show the
information if there are multiple checkouts for now.
I wanted to have all the documentation available on the command line,
but that makes it harder to maintain and link to. Let's move it to
markdown instead. We may later be able to add some way of presenting
the markdown in the terminal (or maybe by first converting it to
reStructuredText).
It's useful to know which commit is checked out in the underlying Git
repo (if there is one), so let's show that. This patch indicates that
commit with `HEAD@git` in the log output. It's probably not very
useful when the Git repo is "internal" (i.e. stored inside `.jj/`),
because then it's unlikely to change often. I therefore considered not
showing it when the Git repo is internal. However, it turned out that
`HEAD` points to a non-existent branch in the repo I use, so it won't
get imported anyway (by the function added in the previous patch). We
can always review this decision later.
This is part of #44.
As @arxanas noted, it's hard to tell which commit is currently checked
out. Hopefully bright colors will help. Maybe setting a background
color would be even clearer, but that's harder to do because the
formatter doesn't support background colors yet.
As #33 says, the default diff we have can be hard to read and it
cannot be used for use with other tools. This patch adds a `jj diff
--git` mode for showing Git's flavor of unified diffs.
We should add a config option to get these diffs by default. For
interchange with other tools, we also need a way of turnning off color
codes in output (it's currently always on, even when when not printing
to a TTY).
The command's help text says "Abandon a revision", which I think is a
good indication that the command's name should be `abandon`. This
patch renames the command and other user-facing occurrences of the
word. The remaining occurrences should be removed when I remove
support for evolution.
With this commit, you can run `jj concepts branches` to get help about
the "branches" concept. We don't have much help for other commands and
their arguments yet, but I'm starting with concept guides so we can
point to them as we add help for commands and their arguments.
I initially tried to make the command to get help be `jj help
--concept branches`. That would require replacing clap's
implementation of the help command with our own. clap-rs/clap#1350
prevented me from doing that. But I'm pretty happy with having it
under `jj concepts` anyway. It's probably more discoverable that way.
I tried to mimic clap's styling with yellow headings.
Now that our own branches and tags are updated when git refs are
updated and the user can use them to specify revisions, we can start
displaying them instead of the git refs. This commit adds new
`branches` and `tags` template keywords and updates the default
templates to use them instead of `git_refs`.
