In the test case `test_branch_mutually_exclusive_actions`, we weren't actually testing anything useful, because the interface has since changed to use subcommands instead of options. The test has been deleted in this commit, and `TestEnvironment::jj_cmd_cli_error` has been changed to return a `#[must_use]` `String` representing stderr. I also added `#[must_use]` to `TestEnvironment::jj_cmd_failure` while I was here.
We currently get the hostname and username from the `whoami` crate. We
do that in lib crate, without giving the caller a way to override
them. That seems wrong since it might be used in a server and
performing operations on behalf of some other user. This commit makes
the hostname and username configurable, so the calling crate can pass
them in. If they have not been passed in, we still default to the
values from the `whoami` crate.
We have talked about showing the commit ID only for divergent changes
because it's generally easier to work with the change ID, and it's
less likely to result in a divergent change. However, it's useful to
have the commit ID available for pasting into e.g. a commit message or
the GitHub UI. To try to steer users towards using the change ID, this
commit moves the commit ID off to the right in the log output.
I put it just after the "divergent" field, because that makes it close
to how I imagine it would look if we decided to hide the commit ID
except for divergent changes. I was thinking that could be rendered as
"divergent (abc123)". So if we add config to hide the commit ID, then
it would be rendered almost the same for divergent commits (just with
the added parentheses). It would also make sense to replace the
"divergent" field by a question mark on the change ID, since change
IDs basically behave like branches. If we do that, then the placement
of the commit ID I picked in this commit does not make sense.
Given how easy this was, I can't believe I didn't make the change
sooner.
I haven't updated the screenshots in the readme because I plan to make
some further changes to the default template. I'll update them after
those changes.
When we export branches to Git, we didn't update our own record of
Git's refs. This frequently led to spurious conflicts in these refs
(e.g. #463). This is typically what happened:
1. Import a branch pointing to commit A from Git
2. Modify the branch in jj to point to commit B
3. Export the branch to Git
4. Update the branch in Git to point to commit C
5. Import refs from Git
In step 3, we forgot to update our record of the branch in the repo
view's `git_refs` field. That led to the import in step 5 to think
that the branch moved from A to C in Git, which conflicts with the
internal branch target of B.
This commit fixes the bug by updating the refs in the `MutableRepo`.
Closes#463.
As I said in the previous patch, I don't know why I made the initial
export to Git a no-op. Exporting everything makes more sense to
(current-)me. It will make it slightly easier to skip exporting
conflicted branches (#463). It also lets us remove a `jj export` call
from `test_templater.rs`.
We had very little testing of the colocated case, so let's add a bit
more before I start working on this code in coming patches. This
includes a test for #463.
Several lines of red text can be overwhelming, and makes it harder to
tell the hint from the error. Let's separate the hint from the error
instead. This matches what hg does. Having the hints separated out
also means that we could have a single config to turn them off.
It's useful to know when you've modified a branch that exists on a
remote. A typical case is when you have pushed a branch to a remote
and then rewritten it. This commit adds an indication in the
`branches` template keyword. A branch that needs to be pushed to a
remote now has a `*` at the end (similar to how conflicted branches
have a `?` at the end). Note that the indication only considers
remotes where the branch currently exists, so there won't be an
indication that the branch has not been pushed to a remote.
Closes#254
The `testutils` module should ideally not be part of the library
dependencies. Since they're used by the integration tests (and the CLI
tests), we need to move them to a separate crate to achieve that.
Unfortunately, TOML requires quotes around the argument. So, the
usage is `jj --config-toml ui.color=\"always\"` in bash. The plan is
to eventually have a `--config` option with simpler syntax for
simple cases.
As discussed in https://github.com/martinvonz/jj/discussions/688.
It seems very likely that we're going to remove support for open
commits, but it's still useful to have a `commit` command that lets
the user enter a description and starts a new change. Calling it
`commit` seems good to make the transition from other VCSs simpler.
The whole file is about the colocated case, where we automatically
import and export on every command, so there should be no reason to
call `git import` here.
The smoke test was useful a year ago, when our CLI test environment
was still annoying enough to use that there were very few tests. We
now have enough tests that the smoke test is not needed.
Mercurial's test runner does something like this.
I considered replacing `\` by `/` everywhere, but we use `\` in
graph-log output quite frequently, so it doesn't seem worth it.
I was trying to create a reproduction script for #412, but the script
ran into another bug first. The script removed all the local and
remote branches from the backing Git repo. I noticed that we would
then try to abandon all commits. We should still count Git HEAD's
target as visible and not try to abandon it. This patch fixes that.
It seems simpler to do the snapshotting after merging any concurrent
operations instead of snapshotting on top of one of the operations,
especially since the attempt to snapshot may end up noticing that the
working copy is stale.
More importantly, snapshotting before resolving operations resulted in
a crash if the working copy was modified. That happened because we
held a lock on the operation heads (`locked_op_heads`) while we tried
to record the operation committing the working copy. I noticed this
only after adding the test.
This commit adds a reminder in `finish_transaction()` if the user
hasn't configured their name and email. That means they'll get a
reminder after most mutating commits, except for commands that only
snapshot the working copy, and a few more cases.
Closes#530.
The native backend is just a proof of concept and there's no real
reason to use it other than for testing, so let's reduce the risk of
accidentally creating repos using it.
I changed the "GLOGAL OPTIONS" help heading to use title case, to
match clap's new help style.
I also removed our override of the help text for `-h, --help` because
the default text now includes "(use `-h` for a summary)" (and it's
harder override now).
Perhaps the most obvious difference to users will be the changed help
output
(https://epage.github.io/blog/2022/09/clap4/#polishing-help-output). It
no longer has color, and long lines are not wrapped. I suppose we
should wrap the text ourselves instead..
