Since operation templates have "operation" label, commit templates should have
"commit" for consistency.
The [colors] table is not updated to use the "commit" prefix. There are some
non-template outputs which use unqualified "bookmark"/"tag"/"git_ref" labels.
That's also a reason why "bookmark_list" template doesn't have a "bookmark"
context label yet. (We'll need to qualify the color definition as "commit
bookmark" so the whole bookmark list wouldn't be colorized as "bookmark".)
I'm thinking of adding a top-level context label consistently. If we added
"commit" to the summary template (in code), the status output would be labeled
as "working_copy commit ..", whereas log entries would be labeled as "commit
working_copy ..". The latter should be more correct since the "commit" label
is global.
Now the working-copy entry is highlighted in op log and bookmark list, which
I think is good.
This assertion is redundant given both the `conflicts_with = "edit"` declaration on the
`no_edit` flag and the passing `test_edit_cannot_be_used_with_no_edit` test.
The `previous_op_id` doesn't belong to the operation immediately before the
`current_op_id`. There is one operation in between, namely the latest snapshot taken.
It isn't necessary to include shebangs in scripts passed into
`util exec` since you're already explicitly calling out the shell you'd
like to use. This change removes shebangs from examples for `util exec`
and adds a note below calling this out.
I'd like to make the internal `jj` binary at Google log the exit code,
but `ExitCode` doesn't seem to provide any way of getting the numeric
code out of it. This patch therefore replaces `ExitCode` by `u8` and
lets the `main()` function convert it to `ExitCode`. It's a bit
unfortunate but I don't see a better solution. It doesn't seem worth
it to create our own newtype for it.
This is just for completeness. I don't think this is practically useful, but the
:<format> syntax should work in both config files and command arguments.
Instead of saying to move configuration files from
`~/Library/Application Support` to `~/.config`, jj now tells you to move
configuration files from `~/Library/Application Support/jj` to
`~/.config/jj`.
The usage line originally showed `--from <REVSETS>|NAMES`, which was confusing as it
could be parsed as `--from (<REVSETS> or NAMES)`, rather than the correct `(--from
<REVSETS>) or NAMES`.
The order of the two arguments are now swapped, so that Clap displays it as
`NAMES|--from <REVSETS>` instead. Using bookmark names as the move targets should be
more common anyway. This is also consistent with the order in which the two arguments
are described in the command's doc comment.
This allows users to override the external tool set in ~/.jjconfig.toml. The
config variable is renamed to ui.diff-formatter to be consistent with the other
diff/merge editor settings.
--tool=:<format> support will be added separately.
Closes#3327
A divergent change could point to more than two commits, so the hint now suggests
abandoning unneeded commits rather than just one of them.
The `-r` flag is unnecessary for `jj abandon` as it is implied.
Also changed `<REVISION>` to `<commit_id>` to be clear that using the change id here
will not work.
This addresses part of #4414 and implements something akin to what's described in
@arxanas's [suggestion], with the exception that the editor contents don’t need to be
completely cleared, since whether cleared or not it is not obvious whether the user
intended to add an empty description or abort entirely.
[suggestion]: https://github.com/jj-vcs/jj/issues/4414#issuecomment-2359123535
The hint is not shown if an empty description is provided via `--message ""`, since the
user is explicitly bypassing the editor and wants to commit the change directly.
Otherwise, if a user exits the editor with an empty description (notwithstanding any
`JJ:` lines), it could be one of the following cases:
1. The user wants to commit the changes but no longer wants to add a description. The
hint can simply be ignored.
2. The user wants to commit the changes and add a description but accidentally exits the
editor. The second hint shows how to add a description to the parent commit.
3. The user no longer wants to commit the changes. However, a new commit is still
created to maintain consistent behaviour as when an empty description is provided via
the CLI. The first hint shows how to undo the commit.
Since jj operates in detached HEAD state, a tracking bookmark isn't technically
needed in order to check out a commit. I usually employ this and delete
unmanaged local bookmarks after cloning repository. This option will automate
the setup.
Since the default remote bookmark is tracked at the end of "jj git clone"
command, it's probably better to show that in the stats output. I originally
implemented it the other way because "git clone --no-checkout" wouldn't create a
local bookmark. However, the tracking bookmark is unrelated to the check-out
state in "jj", so I think it's okay to set up tracking within the "fetch"
transaction.
I often copy and run this command after running `jj git init --colocate`. Having it on a
separate line makes it stand out more and easier to copy, especially if there are many
bookmarks listed.
This is the last part of the series 02722eae54 "view: port bookmark/tag name
types to RefName/RemoteName." Templater doesn't use these name types internally
because we wouldn't gain much type safety in template language.
The return type of .remote() is changed to Option<RefSymbol>. An empty symbol is
rendered with quotes, so it would be weird if local_bookmark.remote() returned
an empty RefSymbol.
the feature reused as much as possible of the `jj rebase` code, with
minimum modifications, in order to avoid reimplementing or complexifying
the rebase code.
It leads to some cases where some commits may be rewritten twice.
For example:
❯ jj -s
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file1
│ A file2
◆ zzzzzzzz root()
❯ jj split -r u -A m -m file1 file1
Rebased 3 descendant commits
First part: ulpvupsv aaf064bc file1
Second part: uttlrpzl 0d4358c2 file1&2
Working copy (@) now at: ylrkuwto 60d905c5 (empty) (no description set)
Parent commit (@-) : qsorlqym 8cfbe2d8 file4
❯ jj -s
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ ulpvupsv file1
│ A file1
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file2
◆ zzzzzzzz root()
There is an intermediate state created as
@ ylrkuwto (empty) (no description set)
○ qsorlqym file4
│ A file4
○ mmkvzzpw file3
│ A file3
○ uttlrpzl file1&2
│ A file2
○ ulpvupsv file1
│ A file1
◆ zzzzzzzz root()
where the commits in `uttlrpzl::` have been rewritten, then `ulpvupsv`
is moved, effectively rewriting the commits in `ulpvupsv::`.
The number of user visible rewritten commits is accurately reported.
`jj split --parallel` is still done as a special case: implementing
it with the rebase code would put the first commits on the right
branch.
