It seems that at least examples are not included in the default set of
targets, and we clearly want to check that the examples compile, as
that's an important reason we have them. We don't have any tests for
the examples yet, but let's add the flag now so we don't forget it
later.
This gets used by `nix develop`, or automatically by `direnv` if you have it
installed.
The binary versions are pinned to the versions recommended by `contributing.md`.
```
>> cargo --version
cargo 1.60.0 (d1fd9fe 2022-03-01)
>> rustc --version
rustc 1.60.0 (7737e0b5c 2022-04-04)
>> cargo fmt --version
rustfmt 1.5.1-nightly (3984bc5 2023-01-17)
>> cargo clippy --version
clippy 0.1.60 (7737e0b 2022-04-04)
```
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.
By inlining `wite_commit_internal()` into `write_commit()`, we can
avoid redoing some steps when we retry. This includes taking the mutex
lock, and reading the tree object and parent commits. It also means
that we avoid cloning the input commit object, which we otherwise
would even in the non-retrying case. I haven't measured if any of this
makes a significant difference, but I think it also slightly
simplifies the code, so it doesn't have to.
This is fast enough to be used on medium-sized repositories such as git/git.
It is a bit slow, but bearable, on huge repositories such as torvalds/linux.
There is 0 performance penalty if the display of unique prefixes is disabled
A trie-based implementation will be submitted for consideration in a
follow-up PR. It is faster, but more complicated.
**Update:** I also just discovered https://sapling-scm.com/docs/internals/indexedlog/
There are three important aspects of performance that seemed relevant:
1. Speed of computing the shortest unique prefix per id. It is worlds faster
than the naive implementation before this commit. It can be optimized
furher by using a trie or maybe the `fst` crate.
2. Speed of inital loading of the index that happens before the first commit is
shown. This is the part that's noticeable but bearable on torvalds/linux.
This could be optimized by storing a sorted list of commit and change ids on
disk. This would likely involve reworking the `Index`.
Failing that, the speed of inital loading doesn't change if a trie is used
and would likely be worse with the `fst` crate
3. Memory use is unremarkable here. I don't have good tools to measure it
precisely, but it does not balloon to gigabytes even on the linux repo.
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.
Fixes https://github.com/martinvonz/jj/issues/1050
Thanks to Martin for suggesting the exact fix.
The tests go into the new tests/test_duplicate_command.rs, which will be
expanded shortly with other tests depending on this bugfix.
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.
You may use "abc\\" in .gitignore to ignore a file named "abc\". In this
case, removing training spaces on "abc\\ " must result in "abc\\" as the
trailing space is not escaped, the preceeding backslash being part of
the previous "\\" escaping sequence.
- branches has the signature branches([needle]), meaning the needle is optional (branches() is equivalent to branches("")) and it matches all branches whose name contains needle as a substring
- remote_branches has the signature remote_branches([branch_needle[, remote_needle]]), meaning it can be called with no arguments, or one argument (in which case, it's similar to branches), or two arguments where the first argument matches branch names and the second argument matches remote names (similar to branches, remote_branches(), remote_branches("") and remote_branches("", "") are all equivalent)
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.
