This helps us to migrate commit_id index to ReadonlyIndex. For large
repositories, this also reduces initialization cost, but that's not the main
intent of this change.
https://github.com/martinvonz/jj/pull/1041#issuecomment-1399225876
common_hex_len() and iter_half_bytes() are added to backend.rs since more
call sites will be added to index.rs, and I feel index.rs isn't a good place
to host this kind of utility functions.
Make op resolution a closed operation, powered by a callback provided by the
caller which runs under an internal lock scope. This allows for greatly
simplifying the internal lifetime structuring.
I think the intent of '- 1' here is the separator length, which was
originally ':'. Alternatively, we can ensure that prefix + remainder is
always 12 chars.
It's unlikely we'll need to discriminate commit/change id types while
templating, so let's unify them. Since ObjectId trait isn't object safe,
I decided to simply store bytes instead of Box<dyn ObjectId>.
Our internal build at Google needs a custom global flag, which lets
the user pass flags into C++ code we use for our custom backends. This
provides a way of achieving that.
`jj cat` better matches `hg cat` and, of course, `cat`. I apparently
called it `jj print` when I added it in 7a013a59ae because I haven't
found `hg cat` useful for actually concatenating files. That's still
true, and I don't know if we will ever bother to teach `jj cat` to
actually concatenate files, but I think the familiarity of `cat` is
more important.
For reference, Git calls it `git show <rev>:<file>`.
I kept `print` as an alias and added a test for it. I also documented
the test better.
By the way, I've considered adding a command for writing from stdin
directly to a specific commit. If we ever do, it might make sense to
call that command `write` (e.g. `echo foo | jj write -r @-
README.md`). Then it would make sense to add `read` as an alias to
`cat`. I'm not sure that's a good idea, but let's leave that for later
anyway.
I'll make WorkspaceCommandHelper inaccessible while transaction is in
progress. This will probably clarify which repo the caller expects to
operate on.
This creates a templater function `short_underscore_prefix` for commit and
change ids. It is similar to `short` function, but shows one fewer hexadecimal
digit and inserts an underscore after the shortest unique prefix.
Highlighting with an underline and perhaps color/bold will be in a follow-up
PR.
The implementation is quadratic, a simple comparison of each id with every
other id. It is replaced in a subsequent commit. The problem with it is that,
while it works fine for a `jj`-sized repo, it becomes is painfully slow with a
repo the size of git/git.
Still, this naive implemenation is included here since it's simple, and could
be used as a reference implementation.
The `shortest_unique_prefix_length` function goes into `repo.rs` since that's
convenient for follow-up commits in this PR to have nicer diffs.
The `indexmap` crate is used to make `duplicate`'s output have a sane order,
making it easier to test.
It's also used later to remove duplicate revisions in the `abandon` command.
The `git.fetch` and `git.push` keys can be used in the configuration file
for the default to use in `jj git fetch` and `jj git push` operations.
By defaut, "origin" is used in both cases.
resolve_single_rev() would have to parse the template for each revision,
but it's just 5 times at most. Let's start with a simple API. If the template
doesn't capture RepoRef, maybe we can cache it.
I'm going to add 'format_commit_summary(commit) -> String' to replace
short_commit_description(), and it's fundamentally the same as
'write_commit_summary()' except where the output will go. The problem of
adding such method to WorkspaceCommandHelper is that it's super easy to
use wrong repo ref while transaction is in progress. This problem could
be avoided by passing repo ref explicitly, but other methods like
resolve_revset() have the same problem.
One idea to prevent such API misuse is to exclusively borrow the helper:
'start_transaction(&'a mut self) -> Wrapper<'a>'. That's doable, but I'm
not certain that it is the right way to go. Anyway, this isn't the problem
only applies to write_commit_summary(), so I decided to add a convenient
wrapper to WorkspaceCommandHelper.
There are several reasons for this:
* We can more easily skip styling a trailing blank line, which other
internal code then can correctly detect as having a trailing
newline. This fixes the TODO in tests/test_commit_template.rs.
* Some tools (like `less -R`) add an extra newline if the final
character is not a newline (e.g. if there's a color reset after
it), which led to an annoying blank line after the diff summary in
e.g. `jj status`.
* Since each line is styled independently, you get all the necessary
escapes even when grepping through the output.
* Some terminals extend background color to the end of the terminal
(i.e. past the newline character), which is probably not what the
user wanted.
* Some tools (like `less -R`) get confused and lose coloring of lines
after a newline.
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).
So far, configured color rules only support specifying foreground
color, and a better-matching rule completely overrides a worse
match. I'm about to add support for specifying other style attributes,
and I want a rule setting a background color not to be overridden by a
rule setting a foreground color. For that to work, it's not enough to
just find the best match, so this commit rewrites the algorithm for
finding the desired style so it finds all matching rules instead. It
then starts with the worst match and applies the other matches on top
of it in order or priority. I've implemented that priority to be in
order of the depth of matching labels, starting with deeper (more
specific) labels. The new algorithm doesn't care about how many labels
match.
We want to be able combine styles by replacing only some of the
attributes (foreground color, underlining, etc.) in the config. We
could implement that having keeping the current style and then update
it based on what we find in the config for a label we just
added. However, it's simpler if we can parse a configured style
without knowing the current style and just return a `Style` with some
fields blank. This commit prepares for that by making the foreground
color field optional.
I'd like to add support for at least bold font, background color, and
underlining. This commit adds a `struct Style` to store that
information. For now, it just contains the foreground color.
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.
The implementations of `add_label()` and `remove_label()` had a lot of
duplicated code, and we would soon have more duplication if we didn't
extract it to shared function.
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.
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.
