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.
This will prevent half-written content on disk in case the write is interrupted.
Lock files are *not* used as the assumption is that a lock is held centrally.
We still need to fix the off-by-one bug affecting hunk end lines. When we add start_line + line_count we end up with an extra line. For example, with start_line 1, and line_count 1, the range is 1:1, not 1:2.
- 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.
Previously, errors would be 'unfolded' so there was no error chain,
but the lowest error would become the top-most one that way.
I thought this was accidental, but it turns out that it wasn't.
To fix this generally, make sure that we always use the message
of the lowest-possible error if no context is provided.
This also rewrites some other checks in preference of opening the git directory
in isolation. Doing so is very fast, and the only way to know for certain if a
repository is bare.
In future, once the repository is more separated from the worktree (in terms of mindset)
it should be possible to handle bare repos with worktrees as well.
The issue initially was that the wrapping of anyhow around a `thiserror`
type, which is when manually added context gets lost as there is no way
to downcast such an `anyhow` error back to a concrete type without
wanting to know it.
The solution was to remove the intermediate `thiserror` type which didn't
serve an actual purpose.
- 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.
Note that the comment above 'deltas' merely removed, as it wasn't actionable
without changing the frontend, which can probably already deal with
multiple of these.
Now that types are better understood though, it was straightforward to
change the type of `file_path` to not be a string, which now is even
clearer of a necessity thanks to the `tauri`-independent `watcher` crate.
Also, remove a comment related to the lack of worktree support.
It now fails gracefully, and that will come up again if support should be added.
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.
Instead, fail gracefully by displaying fill-characters.
Ideally, we would be able to use the commit-encoding header field as well,
but one step at a time.
This will make the diffing engine more correct overall, as only for
display there will be a potentially lossy conversion.
This will also prevent it to be considered binary even though it is not.
Previously, the attempt was made to enable only those `tokio` features
that are actually used. However, due to default-features still being
enabled and `tauri` using the `full` feature, for most intents and purposes
that wasn't effective.
Now default features are disabled, and `full` isn't used anymore, forcing
all crates to mention the exact features they need.
Note that `tracing` is missing here, as it wasn't effective previously
without the `--cfg tokio_unstable` option also being specified as rustflag.
Previous implementation of `joined` would fail this test:
```
st virtual_branches::r#virtual::tests::joined_test ... FAILED
at crates/gitbutler-core/src/virtual_branches/virtual.rs:4139:9:
assertion failed: joined(2, 3, 1, 4)
```
Previously it would watch every registered project, which could incur more work
on all parts of the application than necessary.
Now UI sends an event that indicates which project is active, allowing the
watch to be setup in that very moment. It's worth noting that the previously
watched project is automatically deregistered.
Previously, each file change both in `.git` as well as in the worktree would
cause a complete recomputation. This computation included opening a git
repository at least once (probaby more often), to make an 'is-ignored' check.
The latter is very expensive in `git2` and gets more expensive the more
files there are.
Now the repository is opened when needed, and we re-use it for all applicable
file paths.
The idea is that we don't parallelize over a channel anymore, but
instead just process filesystem events, one at a time.
This would allow each handler to become a function that gets its
state passed, and makes all the necessary calls verbatim, which
in turn makes it easy to follow what's happening.
If anything becomes to slow due to the serialization of event processing,
selective parallelization can be re-added.
Sub-Handlers are objects, and with that comes a lot of complexity.
However, there seems to be on need for it at all, and a first
steps is to turn these into methods to truly understand
what's going on.
This is done one-time (for now) using a nightly feature of cargo-fmt
as defined in `rustfmt-nightly.toml.`
It's planned to make this the default so imports will always be sorted.
For now it can be run manually with:
cargo +nightly fmt -- --config-path rustfmt-nightly.toml
or
pnpm rustfmtTBD
Please enter the message for your patch. Lines starting with
