Commit Graph

12 Commits

Author SHA1 Message Date
Kiril Videlov
acee9ba5ab
move branch related modules to separate crate
Unfortunatelly diff and branch types form a cyclical dependency via the "HunkLock" type. This will have to be refactored as a followup
2024-07-09 00:10:55 +02:00
Kiril Videlov
0c9c781bd5
Renaming crate gitbutler-branch to gitbutler-virtual
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)
2024-07-08 20:56:00 +02:00
Kiril Videlov
83a1d4a1e5
extract user as its own crate out of core 2024-07-08 18:58:29 +02:00
Kiril Videlov
f042854b1c
combine the assets proxying implementaiton in one file
Now it's only used in one place
2024-07-08 18:23:51 +02:00
Kiril Videlov
e93896621f
move project module in a separate gitbutler-project crate 2024-07-08 15:33:26 +02:00
Kiril Videlov
e258710502
move ProjectRepo into its own crate
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
2024-07-08 13:23:03 +02:00
Kiril Videlov
ce497ef7cd
move rebase module to a new repo crate 2024-07-08 00:27:17 +02:00
Kiril Videlov
6dcbb8bddb
move conflicts module to branches crate 2024-07-07 22:58:48 +02:00
Kiril Videlov
00a77d9327
move branch state into a separate crate 2024-07-07 21:26:07 +02:00
Kiril Videlov
c36f67f148
move oplog to its own crate
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
2024-07-07 20:00:01 +02:00
Kiril Videlov
948c89e8be
move virtual outside of core 2024-07-07 15:51:07 +02:00
Kiril Videlov
7d078de52f
start moving virtual_branches to separate crate
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.
2024-07-07 13:32:35 +02:00