ok/jj
1
0
Fork 0
forked from mirrors/jj
Commit graph

9 commits

Author SHA1 Message Date
Martin von Zweigbergk
0137acd0a8 cargo: release 0.1.1
This release is mostly to fix the regressed binary name (back from
`jujube` to `jj`).
2021-01-03 23:06:46 -08:00
Martin von Zweigbergk
abc9dc1733 cargo: rename crates to names available on crates.io
I'm preparing to publish an early version before someone takes the
name(s) on crates.io. "jj" has been taken by a seemingly useless
project, but "jujube" and "jujube-lib" are still available, so let's
use those.
2021-01-03 10:16:00 -08:00
Martin von Zweigbergk
b820eddde3 commands: add an interactive mode for jj restore
This adds an interactive mode for `jj restore`. It works by first
creating two temporary directories with the contents of the subset of
files that differ between the two trees, and then letting the user
edit the directory representing the right/after side. This has some
advantages compared to the interactive modes in Git and Mercurial:

 * It lets the user edit the final state as opposed to the diff itself
   (depending on the diff tool, of course). I think most users find it
   easier to edit the file contents than to edit the patch
   format.

 * It delegates the hard work to a tool that is already written (this
   is a big advantage for an immature tool like Jujube, but it is not
   an advantage from the user's point of view).

Almost all of the work in this commit went into adding a function that
takes two trees, lets the user edit the diff, and returns a new tree
id. I plan to reuse that function for other interactive commands. One
planned command is `jj edit`, which will let the user edit the changes
in a commit. `jj edit -r abc123` will be mostly about providing a more
intuitive name for `jj restore --source abc123^ --destination abc123`,
plus it will be different for merge commits (it will edit only the
changes in the merge commit). I also plan to add `jj split` by letting
the user edit the full diff, leaving only the parts that should go
into the first commit. Perhaps there will also be commands for moving
part of a commit out of or into a parent commit.
2020-12-26 01:16:19 -08:00
Martin von Zweigbergk
ddf8416d92 git_store: use exponential backoff when retrying note-writing
I have never run into this being a problem in practice, but this
change is a stepping stone for two things:

 1. Using exponential backoff for other locks (in particular the
    working copy).

 2. Making the Git store write a ref for conflict objects, so they
    don't get GC'd (I want to do that before even I start dogfooding).
2020-12-24 23:22:07 -08:00
Martin von Zweigbergk
210405b21a cargo: update dependencies
For no reason other than to stay up to date.
2020-12-24 01:16:55 -08:00
Martin von Zweigbergk
9c8f13608f cargo: update blake2
For no reason other than to stay up to date.
2020-12-24 01:15:38 -08:00
Martin von Zweigbergk
c7ee24727a protobuf: generate code at build-time
I had tried to generate the protobuf code at build time many months
ago, but decided against it because it slowed down the build too
much. I didn't realize there was the
"cargo:rerun-if-changed=<filename>" feature that time. Given that that
exists, it seems like an obvious win to generate the source code at
build time.

I put the generated sources in `$OUT_DIR` (where [1] says they should
be), then include them in the `protos` module by using the `include!`
macro. The biggest problem with that is that I couldn't get IntelliJ
to understand it, even after enabling the experimental features
described in [2].

 [1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#code-generation

 [2] https://github.com/intellij-rust/intellij-rust/issues/1908#issuecomment-592773865
2020-12-24 01:05:17 -08:00
Martin von Zweigbergk
88e7f4a30c tests: start using the maplit crate 2020-12-23 17:32:31 -08:00
Martin von Zweigbergk
6b1427cb46 import commit 0f15be02bf4012c116636913562691a0aaa7aed2 from my hg repo 2020-12-12 00:23:38 -08:00