|
| 1 | +//! The operations log, short: Oplog, is a sequence of restore points, which each restore point implemented as snapshots. |
| 2 | +//! Snapshots contain enough information to restore what we are interested in. |
| 3 | +//! |
| 4 | +//! ### Snapshots |
| 5 | +//! |
| 6 | +//! For simplicity, snapshots of "what we are interested in" is all state that contributes to the GitButler experience, such as: |
| 7 | +//! |
| 8 | +//! * where `HEAD` points to |
| 9 | +//! * the position of all references in the Workspace |
| 10 | +//! - the positions of stash references |
| 11 | +//! * metadata stored in the database |
| 12 | +//! |
| 13 | +//! Note the absence of uncommitted and untracked files, as it's something we'd not want to track for the user - they have to do this |
| 14 | +//! themselves and voluntarily via stashes. We only manipulate data that is stored in Git or that is owned and maintained by GitButler. |
| 15 | +//! |
| 16 | +//! It's controlled by the caller which of these (or parts) are stored and to what extent just as an optimisation. |
| 17 | +//! |
| 18 | +//! ### The Log |
| 19 | +//! |
| 20 | +//! Snapshots are merely Git trees that contain information, and they can be arranged using commits to bring them in order, and to |
| 21 | +//! attach metadata about the operation that created them. |
| 22 | +//! |
| 23 | +//! This is where the Log part comes into play, as it associates commits with these trees, and the parent-child relationships of these commits |
| 24 | +//! form the log. |
| 25 | +//! |
| 26 | +//! #### Undo/Redo |
| 27 | +//! |
| 28 | +//! Undo can be implemented by keeping track of which position in the Log we are currently in using its Head, and by restoring all relevant state |
| 29 | +//! to the snapshot it's pointing to. To support a redo, and if this is the most recent entry in the Log as pointed to by its tip, we'd have to |
| 30 | +//! create another snapshot to capture that state so there is something to go back to. |
| 31 | +//! |
| 32 | +//! From that point on, one can move freely through the log backwards and forwards. Worktree changes complicate this, because it's unclear to me to what |
| 33 | +//! extent we should even handle them - my take is to not keep them in oplog snapshots at all and force the user to stash them away. |
| 34 | +//! |
| 35 | +//! When creating a new snapshot while the head isn't at the tip of the log, for simplicity we "forget" the snapshots between the head and the tip, and |
| 36 | +//! move the tip to the new snapshot instead. |
| 37 | +//! |
| 38 | +//! ### Mode of operation: Side Effect |
| 39 | +//! |
| 40 | +//! When applying a mutation the repository, the oplog runs as side . The *effect* itself changes state, and is expected to either fully succeed, |
| 41 | +//! or leave no trace of ever running. |
| 42 | +//! |
| 43 | +//! This means that snapshots have to be recorded in such a way that they can't be observed until they are committed, which happens only when the |
| 44 | +//! *effect* succeeds. On failure, there is no entry in the oplog. |
| 45 | +//! |
| 46 | +//! ### Status of the implementation |
| 47 | +//! |
| 48 | +//! Right now it's merely a letter of intend with an API sketch that is sufficient to 'record but not persist unless command is successful'. |
| 49 | +//! Note that the `gitbutler-oplog` is still the backbone of this implementation, but modified to the extent necessary. |
| 50 | +//! Legacy commands will always see their restore point created as their failure might leave partial changes that might still be undoable |
| 51 | +//! with the restore point. |
| 52 | +//! |
| 53 | +//! Non-legacy commands can use the [`UnmaterializedOplogSnapshot`] utility to insert the snapshot into the log on successful effects. |
| 54 | +
|
| 55 | +/// This is just a sketch for an in-memory snapshot that isn't observable through the on-disk repository. |
| 56 | +/// It will be committed only if the main effect of a function was successfully applied. |
| 57 | +/// This works only if that effect is known to only apply in full, or not at all (at least in 99.9% of the cases). |
| 58 | +/// |
| 59 | +/// NOTE: if this utility type should really take a `Context` as parameter, it should be in `but-api`. |
| 60 | +pub struct UnmaterializedOplogSnapshot { |
| 61 | + /// The tree containing all snapshot information. |
| 62 | + #[cfg(feature = "legacy")] |
| 63 | + tree_id: gix::ObjectId, |
| 64 | + #[cfg(feature = "legacy")] |
| 65 | + details: gitbutler_oplog::entry::SnapshotDetails, |
| 66 | +} |
| 67 | + |
| 68 | +#[cfg(feature = "legacy")] |
| 69 | +mod oplog_snapshot { |
| 70 | + use crate::UnmaterializedOplogSnapshot; |
| 71 | + use but_oxidize::{ObjectIdExt, OidExt}; |
| 72 | + use gitbutler_oplog::OplogExt; |
| 73 | + |
| 74 | + /// Lifecycle |
| 75 | + impl UnmaterializedOplogSnapshot { |
| 76 | + /// Create a new instance from `details`, which is a snapshot that isn't committed to the oplog yet. |
| 77 | + /// This fails if the snapshot creation fails. |
| 78 | + pub fn from_details( |
| 79 | + ctx: &but_ctx::Context, |
| 80 | + details: gitbutler_oplog::entry::SnapshotDetails, |
| 81 | + ) -> anyhow::Result<Self> { |
| 82 | + // TODO: these guards are probably something to remove as they don't belong into a plumbing crate, neither does Context. |
| 83 | + let guard = ctx.shared_worktree_access(); |
| 84 | + let tree_id = ctx.prepare_snapshot(guard.read_permission())?.to_gix(); |
| 85 | + Ok(Self { tree_id, details }) |
| 86 | + } |
| 87 | + } |
| 88 | + |
| 89 | + impl UnmaterializedOplogSnapshot { |
| 90 | + /// Call this method only if the main effect succeeded so the snapshot should be added to the operation log. |
| 91 | + pub fn commit(self, ctx: &but_ctx::Context) -> anyhow::Result<()> { |
| 92 | + let mut guard = ctx.exclusive_worktree_access(); |
| 93 | + let _commit_id = ctx.commit_snapshot( |
| 94 | + self.tree_id.to_git2(), |
| 95 | + self.details, |
| 96 | + guard.write_permission(), |
| 97 | + )?; |
| 98 | + Ok(()) |
| 99 | + } |
| 100 | + } |
| 101 | +} |
0 commit comments