CommitRef now stores raw author/committer headers and parses them when needed.
Since parsing errors would have been detected at .try_to_commit_ref(), this
patch makes new decode errors propagate as before.
Fixes#8350, #8214
An example of squashing `ysrnknol` into `rtsqusxu`:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "A" (squash destination)
updated in destination
%%%%%%% diff from: vpxusssl 38d49363 "B" (parents of squashed commit)
\\\\\\\ to: ysrnknol 7a20f389 "C" (squashed commit)
-base
+squashed
>>>>>>> conflict 1 of 1 ends
```
Or with only partial changes selected:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "A" (squash destination)
updated in destination
%%%%%%% diff from: vpxusssl 38d49363 "B" (parents of squashed commit)
\\\\\\\ to: selected changes for squash (from ysrnknol 7a20f389 "C")
-base
+selected changes
>>>>>>> conflict 1 of 1 ends
```
Now that we can put the "from" and "to" sides on separate lines, we can
use the normal "(no terminating newline)" comment on each side
separately. This should also be more clear, since previously the
"(no terminating newline)" comment could possibly be confused for
"(removes terminating newline)".
Before:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "commit A" (no terminating newline)
grapefruit
%%%%%%% diff from: vpxusssl 38d49363 "merge base"
\\\\\\\ to: ysrnknol 7a20f389 "commit B" (adds terminating newline)
-grape
+grape
>>>>>>> conflict 1 of 1 ends
```
After:
```
<<<<<<< conflict 1 of 1
+++++++ rtsqusxu 2768b0b9 "commit A" (no terminating newline)
grapefruit
%%%%%%% diff from: vpxusssl 38d49363 "merge base" (no terminating newline)
\\\\\\\ to: ysrnknol 7a20f389 "commit B"
-grape
+grape
>>>>>>> conflict 1 of 1 ends
```
An example with parents `rtsqusxu` and `ysrnknol`:
```
<<<<<<< conflict 1 of 1
%%%%%%% diff from: vpxusssl 38d49363 "description of base"
\\\\\\\ to: rtsqusxu 2768b0b9 "description of left"
-base
+left
+++++++ ysrnknol 7a20f389 "description of right"
right
>>>>>>> conflict 1 of 1 ends
```
Since conflict labels are generally going to be long, this introduces a
new "note" conflict marker (`\\\\\\\`), which can be used to split the
"diff" conflict marker (`%%%%%%%`) across two lines:
```
<<<<<<< conflict 1 of 1
%%%%%%% diff from: vpxusssl 38d49363 "description of base"
\\\\\\\ to: rtsqusxu 2768b0b9 "description of left"
-base
+left
+++++++ ysrnknol 7a20f389 "description of right"
right
>>>>>>> conflict 1 of 1 ends
```
Conflict labels will generally start with lowercase change IDs, so
making all of the text lowercase makes it more consistent. I also
removed the "contents of" text, since conflict labels will already be
long enough, and this text doesn't add anything. Similarly, I removed
the "(conflict 1 of 1)" note from the Git conflict markers since Git
doesn't include this information, and including it would result in extra
long lines once we add conflict labels.
Since String provides more convenient functions for searching/splitting than
OsString, it should be simpler to convert relative PathBuf to String first. The
tricky part is "right-to-left" version of .split_inclusive("/"), but the
original code wasn't readable either.
"if !paths.is_changed()" is removed since the formatting function can now handle
unchanged paths.
copied_path.to_diff() returns Option<Diff<T>> because it seemed silly to compare
before/after paths when the caller knows the entry isn't copied/renamed.
This is an easy part of Git extra table GC. The implementation is quite similar
to SimpleOpStore::gc(). Since we don't delete unreachable "commit" entries from
the table segments, this wouldn't improve runtime performance. Directory lookup
might get slightly faster thanks to fewer file entries, though.
#12, #8312
This is pretty low level, but we can at least know which extras table files are
active. The --key-size parameter doesn't matter so long as it is smaller than
the actual key size, but we might add sanity check later.
It's usually going to be easier for a user to run the same command again
but with a change offset appended, so I think these are more helpful
than commit IDs.
I'm going to add a way to select a specific commit from the set of
commits with a given change ID. We could sort these by committer
timestamp or something else, but index position is convenient because it
doesn't require reading the commits. The exact order isn't too
important, but giving newer commits lower offset numbers is nice because
newer commits are used more frequently.
The goal of this change is to unify defaults of string patterns in revsets and
command arguments. Glob is a good default because it's largely the same as exact
matching, and we can easily express substring patterns with globs.
The hint for "jj git fetch -b<glob>" is deleted since exact:<glob> is now
required in order to trigger the error.
This patch also updates help of clone/fetch --branch patterns. Glob and operator
support in refspecs is limited.
Instead of forking a git process, use `gix` to toggle `core.bare` config.
The original `git -C <repo_root>/.jj/repo/store/git config repo.bare
<true|false>` fails when the user has `safe.bareRepository` config set to
'explicit'. A typical failure looks like this:
% jj git colocation disable
Error: Failed to set core.bare to true in Git config.
Caused by: Git config failed: fatal: not in a git directory
.git is moved to .jj/repo/store/git as a bare repo, and if we run git directly:
% git -C .jj/repo/store/git config repo.bare true
fatal: not in a git directory
% git -C .jj/repo/store/git status
fatal: cannot use bare repository
<repo_root>/.jj/repo/store/git (safe.bareRepository is 'explicit')
Use `gix` to avoid forking git and being interferred by git's configs.
While these two are stored in view objects, we intentionally ignore them when
undoing. This means that these fields don't have to be tracked by
view/operation. I think we can move them away to GitBackend-specific data.
We could provide git_head()/git_refs() that load data from GitBackend, but I
don't think these template/revset functions are useful. I've never used them
except for the git_head() template function, and its use case was to see whether
the repository is colocated or not.
The auto-tracking-bookmarks settings will be parsed as string matcher
expressions. Since it isn't trivial to parse string expressions, the [remotes]
table should be loaded only when needed.
New GitImportOptions type has no from_settings() constructor. That's mainly
because parsing function can potentially emit warnings, and these warnings will
have to be printed.
