Previously, despite `max_log_files()` configured, it would still
retain more than that, and effectively never delete any as that
would only happen on log-rotation.
Now we do it ourselves just once.
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.
Removing the updating of project from the virtual branch controller - this is the only dependency between the two controllers and likely indicates that the "last fetched at" should live somewhere else.
It will serve us well to not mutate the project state from the virtual branches domain
- inject secretService so it works when used directly
- remove console logs
- only remove a migrated secret (instead of removing it unconditionally)
- in +template, await for good measure, which explains why the parent function is async
In the backend:
- prevent concurrency in method that stores secrets from the frontend
as it's racy otherwise to type a secret quickly.
All AI related options are stored in the user-level git configuration
file. Upon first access, they will be removed from there and placed
into the keystore as part of the migration.
The UI is provided with functions to store and save secrets which it
will use specifically to interact with these keys.
It's explicitly out of scope to *not* show the keys in plain-text
anymore after entering them.
MacOS is the only known platform that exhibits this behaviour - if an app
is recompiled, the hash of the binary is used to identify it towards the keychain.
As this changes each time, the keychain will ask for permission, which is fair.
However, it's also an impediment which leads to the implementation of
a keystore that uses git credentials as backend. For this to work,
the latest version of `gitoxide` is required for now.
This does not only mean that they cannot be written to disk, but also
that extra work has to be done to serialize them over the wire.
This is very much by design, as they can be in structs that are
seemingly serializable and contain sensitive data, but they must
never actually be serialized.
For use in the UI, an extra type must be used that marks the secret
differently, for instance by field name.
