With the default config (if global `conflict-marker-style` is not
customized), this reverts the behavior to that before 7f57866332.
`vimdiff` config already shows three panes with the three snapshots for
each conflict, so it's helpful to show jj's diff view in the editing
pane.
In other words, previously the conflict was always shown in the
"snapshot" format in the main pane:
```
<<<<<<< Conflict 1 of 1
+++++++ Contents of side #1
fn has_tracked_remote_bookmarks(view: &View, bookmark: &RefName) -> bool {
------- Contents of base
fn has_tracked_remote_bookmarks(view: &View, bookmark: &str) -> bool {
+++++++ Contents of side #2
pub fn has_tracked_remote_bookmarks(view: &View, bookmark: &str) -> bool {
>>>>>>> Conflict 1 of 1 ends
```
and now it is shown in whatever format the user set as the default. If
the user didn't pick a default, the "diff" format is used in the main
pane:
```
<<<<<<< Conflict 1 of 1
%%%%%%% Changes from base to side #1
-fn has_tracked_remote_bookmarks(view: &View, bookmark: &str) -> bool {
+fn has_tracked_remote_bookmarks(view: &View, bookmark: &RefName) -> bool {
+++++++ Contents of side #2
pub fn has_tracked_remote_bookmarks(view: &View, bookmark: &str) -> bool {
>>>>>>> Conflict 1 of 1 ends
```
See also the screenshot in https://github.com/jj-vcs/jj/pull/6147 to see
the main pane in the context of the three other panes that always
display the snapshots.
This allows callers to mutate RevsetParseContext if needed.
RevsetParseContext was changed to an opaque struct at 4e0abf06317f "revset: make
RevsetParseContext opaque." I think the intent there was to hide implementation
details from revset extension functions. This is now achieved by opaque
LoweringContext.
Another reason of this change is that aliases_map is no longer needed when
transforming AST to UserRevsetExpression.
I tried to minimize this patch, but it seemed rather complicated than porting
most callers all at once. Remote management functions in git.rs are unchanged.
They'll be ported separately.
With this change, many non-template bookmark/remote name outputs should be
rendered in revset syntax.
It's a bit weird that Deref is required, but this helps deduce the query type.
Maybe we can add typed StringPattern wrapper, but I'm not sure if that's a good
idea.
Alternatively, RefNameBuf could implement Borrow<str>, but that means the map
could be looked up by weakly-typed string keys.
These types are akin to ObjectId types, but for refs. Perhaps, WorkspaceId can
be ported to impl_name_type!().
These types don't implement Display because it would be source of subtle bugs
if a string-like type could be formatted differently. For example, we would
have to be careful to not format!("refs/heads/{name}") if the name implemented
a default Display in revset syntax.
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).
It is important for this case to be an error, because otherwise it would
be possible to construct a non-conflicted commit which appears to have a
different tree when viewed using `jj` than when viewed using Git. This
could potentially be used to hide malicious code in commits in such a
way that on GitHub, the code would appear normal, but it would become
malicious when cloned using `jj`.
Prior to f7b14beacc678a9b351ae65224df43a96aa26392, if a commit had a
`jj:trees` header with only a single tree, it would result in a panic of
"root tree should have been initialized to a legacy id". This commit
restores the error behavior by adding an explicit check for this case.
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 have no immediate plan, but I think we can make "jj git export" show exported
refs. The FailedRefExport type is replaced with a plain tuple since we have a
named type wrapping (symbol, reason) pairs now.
We have been writing conflicted tree ids to the `jj:trees` commit
header since 4d426049 (just over a year ago) and we have been able to
read them from there since the same commit. This patch updates the
write path so we no longer redundantly write the trees to the proto
storage.
We write the `jj:trees` commit header since 4d426049. If the
information is written to that header, we should not require it to
also be in the proto storage.
I'm going to change the key type from RefName to RemoteSymbolBuf, but the std
BTreeMap/HashMap doesn't support lookup by un-Borrow-able ref types. We can use
hashbrown::HashMap, but there aren't popular alternative for ordered maps.
Since we don't need random insertion and lookup, we can simply use Vec.
