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.
It's possible that the sempahore state in the virtual branches controller is completely unnecessary. This feature flag allows us to test this hypothesis
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
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.
The frontend uses this to invalidate the GitHub token, even though
it can also deal with `null`. Let's keep the keystore clean and
only keep entries that contain an actual password.
Note that the consumers, i.e. the frontend, handle an empty password
for the short time it's in memory.
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.
This will also remove them from their plain-text location.
Further, when the secrets are required they will be obtained
specifically, instead of always having them at hand.
The frontend doesn't ever show these, but needs them, and
it now asks for them when it needs them.
* Don't return optional
* Rename get_integration_commiter
* Add a header to wip commit
* Stuff
* Unapply all branches
* Reorder code
* Fix one test
* Name resolution
* Fix two tests
* Fix another!
* wip
* Fix so many tests
* Fix unapply.rs tests
* Fix selected for changes tests
* Move unapplying logic to delete_branch method
* Remove unused and kinda borked cherry_commit code
* Fix the tests!!!!!
* Make apply_branch private
* Change handling of headers
* Improve order integrity
* Updated types and comments to convey more meaning
If a user.json file cannot be loaded, delete it automatically
to avoid users to get stuck in 'something went wrong' during layout.
Older versions of GB wouldn't find the access-token in the user.json file
anymore, which would be completely removed via #4165
