description_template_for_*() functions will be merged soon.
We don't need to set the default description to the second commit of the split
because its description should be kept empty if it was.
This could be handled by description_template_for_describe(), but I think it's
better to do mutation by caller. I also think commands like "backout" or "new"
can do a similar thing to generate a default commit description from the source
or merge parent commits.
This will help consolidate description_template_for_*() functions and port them
to templater. This change also means the committer (and operation start)
timestamp is set earlier. I think that's good.
It's wrong to deduce loaded_at_head from command-line arguments if the repo was
loaded at an arbitrary operation. Instead, the caller should specify whether
the working copy state is synchronized with the repo view.
I think .for_loaded_repo(ui, workspace, repo, true) would be bad for
readability, so I added separate functions. I'm not happy with the name
.for_temporary_repo(), but it seems okay for the current call sites.
--at-op should be invalid on repo initialization. "init --ignore-working-copy"
could be supported by using working_copy.reset(), but I don't think it's
worth the effort. If the working directory is empty, --ignore-working-copy
is meaningless, and if the directory is not empty, the user would probably
want to do snapshot at some point.
The user can define the setting `git.private-commits` as they desire. For
example:
git.private-commits = 'description(glob:"wip:*")'
If any commits are in this revset, then the push is aborted.
If a commit would be private but already exists on the remote, then it does
not block pushes, nor do its descendents block pushes unless they are also
contained in `git.private-commits`.
Closes#3376
The user probably would expect the path to be relative to their current
directory rather than the workspace root. For instance, if the user is
in a child directory and runs `jj workspace add ../../name`, then they
might be surprised if we printed "../name" instead of "../../name".
Prevents a warning from being printed when renaming branches in a
colocated repo, since git tracking branches were being considered as
remote tracking branches.
Now that `jj move` does not accept `-r` (since it has `--from` and `--to`), `jj set --to` seems more useful
than `jj set -r`. `create --to` is also added for ease of switching
between `branch create` and `branch move`.
Currently, when there is a commit with two predecessors, the graph
splits into two branches, and all of the predecessors on the first
branch are printed before all of the predecessors on the second branch.
This causes the graph to grow wider with each squashed commit, since the
second branch must always get indented one level farther each time a
commit is squashed. I have some commits where the graph is indented more
than 10 levels due to squashing more than 10 times, making it very
difficult to read.
Reversing the order and printing the second branch before the first
branch prevents this unnecessary indentation and makes the graph easier
to read. This does not change the order of the edges in the graph (i.e.
the first predecessor is still the first edge and the second predecessor
is still the second edge in the graph).
Adds support for revset functions `tracked_remote_branches()` and
`untracked_remote_branches()`. I think this would be especially useful
for configuring `immutable_heads()` because rewriting untracked remote
branches usually wouldn't be desirable (since it wouldn't update the
remote branch). It also makes it easy to hide branches that you don't
care about from the log, since you could hide untracked branches and
then only track branches that you care about.
Partially resolve a 1.5‐year‐old TODO comment.
Add opt‐in syntax for case‐insensitive matching, suffixing the
pattern kind with `-i`. Not every context supports case‐insensitive
patterns (e.g. Git branch fetch settings). It may make sense to make
this the default in at least some contexts (e.g. the commit signature
and description revsets), but it would require some thought to avoid
more confusing context‐sensitivity.
Make `mine()` match case‐insensitively unconditionally, since email
addresses are conventionally case‐insensitive and it doesn’t take
a pattern anyway.
This currently only handles ASCII case folding, due to the complexities
of case‐insensitive Unicode comparison and the `glob` crate’s lack
of support for it. This is unlikely to matter for email addresses,
which very rarely contain non‐ASCII characters, but is unfortunate
for names and descriptions. However, the current matching behaviour is
already seriously deficient for non‐ASCII text due to the lack of any
normalization, so this hopefully shouldn’t be a blocker to adding the
interface. An expository comment has been left in the code for anyone
who wants to try and address this (perhaps a future version of myself).
`tx.format_commit_summary()` can be expensive because it needs to build
an IdPrefixContext now, so it's best to avoid formatting instruction
messages unless they are actually required.
For the same reason as the previous commit.
Created and moved stats are printed separately because it's unusual to do both
within one "branch set" invocation.
For the same reason as cdc0cc360162. This will help notice problems like wrong
target revision.
The warning for multiple branches is reorganized as a hint for "-r" option,
which I think is the main purpose of this warning. Unlike "squash", we don't
check if an argument can be parsed as a revset because branch name is usually
a valid symbol expression.
Forgetting a workspace removes its working-copy commit, so it makes
sense for it to be abandoned if it is discardable just like editing a
new commit will cause the old commit to be abandoned if it is
discardable.
It's nice to see the result of "branch move", "create", etc., and this is more
important in "branch move" because the source branches can be specified in an
abstracted way. I originally considered printing a list of affected branches,
but it looked rather verbose. Since the destination revision is unique, we can
use commit_summary template instead.
This patch also removes a warning about multiple branches because the branch
names are included in the commit summary. I think the hint message is good
enough to signal possible mistake.
We usually print stats at the end of mutable operation, and I think these
messages are useful even if N = 1. I understand that "Deleted N" (N > 1) is
unusual and the original intent of these messages was to signal possible
mistakes. However, I don't think printing N=1 stats would nullify the original
purpose.
No emptiness check is needed for delete/forget, but names can be empty in
track/untrack because of noop changes.
At work, a user encountered a panic upon attempting to create a dir at
the line in the diff below, but it turned out to be difficult to debug
because I didn't know what the path was. There already is a mechanism to
add path context in the lib crate; make it available in the cli crate as
well, and use the mechanism to add path context to "workspace add".
Now, the command for `jj git remote add` is `cmd_git_remote_add` and its
argument type is `GitRemoteAddArgs`. This should make it easier to find
the CLI docs and the implementation for commands.
This is how `jj branch` commands were already set up in this way. The
`jj op` commands were also already set up in this way, except the
functions are called e.g. `cmd_op_undo`, I kept this for simplicity.
I was mainly motivated by the `jj file` commands. Most other commands
had functions already named in the above pattern, but used to have
shorter argument type names.
We have two other kinds of working copies at Google and it's sometimes
useful to get the basic information about operation id and tree id for
them, for exampel for debugging stale workspaces. This patch adds a
command for that.
We could instead have made the old `jj debug working-copy` command
work for all kinds of working copies (like the new command) and only
have extra information for the standard local-disk implementation. I
don't feel strongly either way and could do it other other way instead
if people prefer that.
