Sturdy came up a while ago on lobste.rs when [jj was being discussed](https://lobste.rs/s/47zztj/jujutsu_dvcs). I'm not sure if I described it well, or if it's something you want as related-work, especially since the sturdy founder claims to be solving different problems in the very thread. But it does seem to be doing some similar things to removing the idea of an index/staging area.
Since whitespace change is barely visible in color-words diff, I think it
would be too verbose to add "\ No newline at end of file" marker. Let's just
append missing newline to make the command output readable.
We had a recent bug where we used a repo reference from before we
started a transaction and modified the repo. While it's often safe and
correct to use such references, it isn't always. This patch removes
all such cases. I think it generally makes the code clearer, and
better prepared for #50, if we ever get around to that. I found these
by temporarily making `WorkspaceCommandHelper::start_transaction()`
take a mutable reference.
The `CommitBuilder::store` field is used only in
`CommitBuilder::write_to_repo()`, but we can easily get access to the
`Store` from the `repo` argument there, so let's remove the field.
In the `jj git push --change X` code, we start a transaction and then
resolve the argument, which often results in the working copy getting
snapshotted. Since the snapshotting happens in its own transaction,
that means we have two concurrent operations for no good reason. This
patch fixes that by starting the main transaction a little
later. Since that restructuring made it easy to give more detailed
descriptions to the operations, I also did that.
The operation log entry for `jj git push` currently says "import git
refs". That seems like just a bad copy&paste. While it used to be
technically correct that the only effect on the repo was from the
import, now that we have the `jj git push --change`, that is no longer
even true.
It's convenient to push all changed branches every time with `jj git
push`, but sometimes I want to know which branches were actually
pushed. This make the command print what it's going to do.
I'll add a `--dry-run` mode and tests next.
I think I had not added tests for successful push before because I
thought there was some issue with testing it with libgit2. There *is*
an issue, which is that libgit2 requires the remote to be bare when
it's on local disk, but we can very easily make the git repo bare in
this test.
I also updated the error handling in the `git` module to not let
follow-on errors hide the real error and to not fail if two branches
moved to the same commit.
Fetching is typically much expensive than checking out, so if fetching
completes but checking out fails (due to some bug, perhaps), it seems
better to commit the fetch transaction. That way, the user can inspect
the repo and try checking out again.
We used to check only if the destination already had a `.jj/`
directory. This patch changes that to check that the destination is an
empty directory.
Closes#399.
We didn't seem to have any. I included a test for #399.
The tests also showed how the debug formatting (`{:?}`) results in
escaped (e.g.) backslashes on Windows, which is not what we want, so I
also fixed that.
By adding `ui.open-commits=false` in your config, you can now make `jj
checkout` always create a new working-copy commit on top of the
specified commit. If the config is set, open commits will also appear
in the same color as closed commits in `jj log` etc. This will let
some of us experiment with the new UX before we decide if it's a good
idea or not. I left `jj close` in place because it's useful for
setting a description and creating a new commit in one step.
I didn't mention the new config in the release notes because I hope we
can reach a decision and remove the config before the next release.
When rebasing commits after rewrites, we also update all workspaces'
checkouts. If the new commit is closed, we create a new commit on
top. Since we're hoping to remove the open/closed concept, we need a
new condition. I considered creating a new commit on top if the change
ID was different from before the rewrite. However, that would make at
least `jj split` more complicated because it makes the first commit
keep the change ID but it wants the second commit to be checked
out. This patch instead creates the new commit on top only when the
original commit was abandoned.
When a commit gets rewritten, we update any workspaces pointing to the
old commit to check out the rewritten commit. If the rewritten commit
is closed, we create a new working-copy commit on top of it. Since
we're thinking about removing the open/closed concept, we need to make
`jj close` manually create the new working-copy commit.
I think it's conceptually simpler to create a new commit and set that
commit to be the checkout in each workspace than to check out the
commit in one workspace and edit in the others.
I'm about to change how `jj checkout` works w.r.t. open/closed commits
(and in particular by moving some logic from the library crate to the
CLI), so let's make sure we have some test coverage.
