It's used for emission of changed files, but also for listing
branch information.
Make sure we only run the worktree-status once to save time.
This also unifies the acquisition of the `HEAD^{commit}`,
which one day will be a natural feature once `gix::Repository`
is used.
That way it's assured that reads and writes don't intersect, but assure we only
hold such lock for the shortest amount of time for reads and and for the
full duration of writes.
* use `ctx` as name instead of `project_repository` to make lines shorter
and more readable. This could be done everywhere once the type-name changes
as well.
* Where possible, avoid using `&self` for `VirtualBranchActions` as there is no state.
For now I avoided to remove its usage as field in the filesystem monitor.
* Use a more modern way to use state in `tauri` commands.
* Add the `Ext` suffix to what clearly is extension traits.
The frontend should be better at this due to being a browser engine, which can naturally
handle slow network links and firewalls.
Caching should also be better and more consistent as cache-related headers are respected.
This should speed up display times of new branches significantly, ideally without blocking
the UI at all.
This is more descriptive to what logic lives inside. Further, this allows for splitting up the just branch bits in a separate crate (which is currently in gitbutler-core)
This type currently acts more or less like a command context that lives for the duration of the request. Regardless of if we wanna keep this pattern or not, separating it out helps us split up core
This protects us from cyclic dependencies. Unfortunatelly as part of this, i had to introduce the imp Project as trait implementations since now Project is foreign
We want to move towards having each functional domain in a separate crate.
The main benefit of that for our project is that this will enforce a unidirectional dependency graph (i.e. no cycles).
Starting off with virutal_branches - a lot of the implementation is still in core (i.e. virtual.rs), that will be moved in a separate PR.
Furthermore, the virtual branches controller (as well as virtual.rs) contain functions not directly related to branches (e.g. commit reordering etc). That will be furthe separate in a crate.
- instrument snapshot creation to assure we see errors (which are ignored in code)
- move tests for public `entry` types into integration tests
- rename `OperationType` to `OperationKind` as it's more commmon in Rust
- Use `Copy` where possible
- streamline implementation: remove clones and allocations, without going zero-copy
- Prefer direct calls to traits to avoid `write!("{}")` just to invoke a trait fmt implementation
- avoid `pub` when `pub(crate)` will do
- strong type for created_at
:Repository shell type