Since 7618b52b "cli: consider 'JJ:' lines as comments also when not followed by
space", lines starting with "JJ:" (without space) are also ignored. We can
simply add "JJ:" prefix to empty intro/instruction lines.
Closes#5484
This helps detect whether the last line is "JJ:" instruction or not. It seems
also nice that I don't have to insert newline to reflow the edited paragraph.
A subset of cli tests could fail if the system /etc/gitconfig had
configuration interfering with the tests. The cause seems to be running
of `jj` commands that would in turn use a `git` subprocess.
Fix this by setting `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL`, like
in `hermetic_git`.
Fixes#6159
It's deprecated since 1aad25042029 "Shorten the git push branch when possible
using the short change ID hash" (2023-01-12). I don't think we need the
fallback. I also removed the check for ambiguous prefixes as I believe it
wouldn't practically matter. If needed, we can add a check for existing bookmark
pointing to different commit. We can also make it templated with default
"'push-' ++ change_id.shortest(12)".
Previously, the completions suggested the literal string:
`{f_not_yet_renamed => f_renamed}`. Instead, the old and new file names
should be completed separately.
Previously, the "renamed" file wasn't deleted at its old location, so it
wasn't renamed at all. Correcting this reveals a bug in the completions
of renamed paths. The completions suggest the literal string:
`{f_not_yet_renamed => f_renamed}`. Instead, the old and new file names
should be completed separately.
We've been finding that a lot of bug reports on `jj git push` come from
sub-standard error reporting on the reasons the failure happens.
It can come from a number of places:
- hook failure
- remote branch protection
- git config
This commit forwards the reason as explained by the ouptut of git push
to help users figure out what is happening.
We need to report more complicated errors on push.
Firstly, we can have a mix of unexpected ref locations and remote
rejections. We should report both at the same time.
Second, git gives us a reason for why a push failed.
For this to work, it's relevant to refactor the current error reporting
path to allow us to inject this information.
This is to ensure two things:
1. That the evolog isn't missing the history from the target commit.
2. That the evolog doesn't include extra "temporary" commits due to
the way `jj split` is implemented.
The impetus for this is the discussion in https://github.com/jj-vcs/jj/pull/5926.
The changes added here detect the extra temporary commit added to the evolog
when `split --parallel` is run using the implementation in #5926.
In colocated repos, we set up the Git index to make `git diff` closely
match `jj diff`. However, `git diff` will not include new files. We're
long talked about using the `git add --intent-to-add` feature to make
the match closer. This patch implements that. It does so both after
updating the working copy and after snapshotting. After updating the
working copy, the new file in the working-copy commit (compared to the
parent(s)) are marked as intent-to-add. After snapshotting, newly
snapshotted files are marked as intent-to-add, and deleted ones that
were previously marked as intent-to-add are removed from the index.
Closes#6122
I'm about to set the intent-to-add flag for newly added files. It's
also somewhat useful to see the index flags for conflict stages (the
different stages).
The git remote sideband adds a dummy suffix of 8 spaces to attempt to clear
any leftover data. This is done to help with cases where the line is
rewritten.
However, a common option in a lot of editors removes trailing whitespace.
This means that anyone with that option that opens this file would make the
following snapshot fail. Using the insta filter here normalizes the
output.
It wasn't immediately obvious to me what was happening here, but once I
understood it it seemed pretty simple. Perhaps it's worth a comment to explain
it to the next reader.
I usually don't read these messages carefully, and the red "(conflict)" label
looked scary. Suppose we don't have to take further action on resolved commits,
I don't think we need to print commit summary for each resolved commit.
This moves the default template to `builtin_draft_commit_description` and
points `draft_commit_description` to it. This makes it easier to override
the template while still being able to refer to the default.
