The changes in this commit optimize the sorting of virtual branch files
by pre-computing the index positions of the ownership claims for each
file path. This improves the performance of the sorting operation by
avoiding the need to repeatedly search for the index positions during
the comparison step.
With 1900 hunks in a vbranch, I've found that this helps reduce the run time from 9 seconds down to just 5.
I considered not sorting at all if we didn't have any branches, but this didn't provide any substantial change in performance.
- drop "double lock across branches" test because it can't happen
- save correct tree when updating branch states
- use correct integration commit when updating base branch
this adds backend functions in Rust to do the following:
* move file hunks between commits (basic)
* undo any commit in a stack
* insert a blank commit
* move a commit within the stack
* update a commit message in place
GB writes files atomically and in the end it boils down to allocating bytes
and writing them all at once.
Now this capability lives in the `fs` module.
Instead, respect the existing bit if set in Git, but do not try
to derive it from the filesystem which is something Git doesn't
seem to be doing on Windows either.
This also makes me think that `gitoxide` should make it easy
to build a tree from a file and deal with this.
- replaces commit walking with a git blame
- limited to specific hunk lines
- earliest_commit set to default target
- lock if any blame other than boundary commit
- intersection uses context lines
Sometimes, symbolic refs are used as tracking branches, like
`refs/remotes/origin/HEAD`, and after some changes are dangling,
pointing to a ref which doesn't exist anymore (maybe it was renamed
from `master` to `main`).
Now, this isn't fatal anymore, but will be logged instead.
In the previous commit it was stated that the 'unfolding' of errors might
have been intentional to surface root causes of error messages.
However, this might have been wrong, and this commit brings back root-causes explicitly,
while erroring on the side of caution. That is, "Something went wrong" probably won't
be shown anymore, instead, possibly too much will be displayed and we'd rather tune
that down once it becomes clear which messages are needed, or should be improved.
Overall, I think it's best to show more, and then tune errors with custom context
where needed.
- assure that `repository` can't be misused in `hunks_by_filepath()`.
- Use more obvious enumeration to describe and match on lines
- make clear that diff_lines can be a hash
- avoid multiple hashmasps if one would do
- `Hunk::hash_diff` now uses lines with terminator to be close to being a true content hash. This was probably intended by the code originally.
The input is variable and maybe empty, maybe a diff header followed
by diff-lines, and it could be an SHA1 of a binary file, which now is
hashed like any other content.
If for whichever reason the parsing of parts of the vbranch.toml file
fails, this would be a permanent error until the file is fixed or removed.
Now it's also displayed along with the error to make clearing the file
more convenient.
