This reverts commit b8ca9ae and adds a comment.
In commit 4d42604 (a year ago), we started writing the trees involved in
conflicted commits to the Git commit object in addition to the proto
storage. We validated that the two record matched when reading commits
until as recently as f7b14be (about a week ago). Just after that, in
commit b8ca9ae, we stopped writing the tree ids to the proto storage.
That means that any version of jj between 4d42604 and f7b14be would
error fail when reading a conflicted commit created by new versions.
While we don't guarantee forward compatibility, it's easy to do so here,
so let's be friendly to older versions by rolling back b8ca9ae so we
continue to write the conflicted tree ids to both places for a while
more.
(Thanks to Martin for the detailed explanation!)
Fixes https://github.com/jj-vcs/jj/issues/6185
I think this makes more sense because WorkspaceId is currently a human-readable
name. In error/status messages, workspace names are now printed in revset
syntax.
New WorkspaceId types do not implement Default. It would be weird if string-like
type had non-empty Default::default(). The DEFAULT constant is provided instead.
Wrapped errors are usually displayed after "Failed to import refs ...", etc., so
the context is obvious. I also removed "Internal"/"Error" for consistency.
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.
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
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.
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.
When used inside GUI application, enabling GPG or SSH signing causes console window to appear temporarily.
std::process::Command needs special flags to prevent that. More details: https://stackoverflow.com/a/60958956
When used inside GUI application, git.subprocess=true option causes console window to appear temporarily.
std::process::Command needs special flags to prevent that. More details: https://stackoverflow.com/a/60958956
