The conditions for triggering Nix builds and other builds were
slightly different.
Nix builds triggered by PRs happened on PRs for any branch, not just
the `main` branch. That makes very little difference in practice
because PRs for other branches are very rare. Still, let's be
consistent. I decided to trigger the builds on PRs for any branch.
More importantly, Nix builds triggered by push were only done for
pushes to `master`, which is not what our main branch is called, so
those never happened.
The biggest difference in the API is that fields are now public. The
exception from that is `oneof` fields, which still require setters and
getters.
I couldn't measure any difference in performance. I didn't expect any
difference either, but it's good that it didn't seem to regress. I
timed `jj debug operation <some hash prefix>`, which will read the
whole operation log (to check that the prefix is unambiguous).
Tree merges can currently fail because of a failure to look up an
object, or because of a failure to read its contents. Both results in
`BackendError` because of a `impl From<std::io::Error> for
BackendError`. That's kind of correct in this case, but it wasn't
intentional (that impl was from `local_backend`), and we need to
making errors more specific for better error handling.
Apparently, I need to pass `--merge` option to use kdiff3 as a diff editor.
We could add `diff-editor-args` or extend `diff-editor` to a list of command
arguments, but we'll eventually add stock merge tools and the configuration
would look like:
[merge-tools.<name>]
program = ...
diff-args = [...]
edit-args = [...]
merge-args = [...]
Since 57ba9a9409, if the automatic import from git results in some
abandoned commit, that information gets recorded in the `MutableRepo`,
but I forgot to add a call to rebase the descendants. That causes a
failed assertion at
81a8cfefcb/lib/src/transaction.rs (L86). This
patch add a test showing that failure.
I think I copied the name `write_tree()` from Git, but I find it quite
confusing, since it's not clear if it write a tree to the working copy
or reads the working copy and writes a tree to the store (it's the
former).
Used to produce a message like this:
```
thread 'main' panicked at 'failed to run diff editor: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/diff_edit.rs:136:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Now produces a message like this:
```
Error: Failed to edit diff: Error executing editor 'meld': No such file or directory (os error 2)
```
This adds `jj git push --change <revision>` which creates a branch
with a name based on the revision's change ID, and then pushes that
like with `--branch`. That can be useful so you don't have to manually
add the branch (and come up with a name for it). The created branch
behaves like any other branch, so it's possible to make it point to a
commit with a different change ID.
This is actually enough to fix#248, but I'll continue to work on
error handling for a while. I'd like to at least include the bad
object ID in this type of error messages.
Closes#248.
As requested by @talpr. I added this is a separate new command `jj git
remote list`. One could also imagine showing the listing when there is
no sub-command specified to `jj git remote`, but we don't have other
commands that behave that way yet.
Closes#243
It seems to me that we have never created a Git index in order to
create a commit, not even in the earliest versions of the code (before
it was moved to Git).
Now that I'm using GitHub PRs instead of pushing directly to the main
branch, it's quite annoying to have to abandon the old commits after
GitHub rebases them. This patch makes it so we compare the remote's
previous heads to the new heads and abandons any commits that were
removed on the remote. As usual, that means that descendants get
rebased onto the closest remaining commit.
This is half of #241. The other half is to detect rewritten branches
and rebase on top.
