Vault merge conflicts and vault pull/clone edge cases

[scottmmorris]

When pulling changes for a vault, if merge conflicts arise, they need to be rejected at this stage as there is no ability for users to resolve the merge conflicts

Also, the edge cases for vault cloning and pulling need to be considered. For example, if a user clones a vault and while pulling from the vault the git history does not match the expected results this should be rejected

Additional Context

• https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205 - vaults review/refactoring
• https://gitlab.com/MatrixAI/Engineering/Polykey/js-encryptedfs/-/merge_requests/46 - encryptedfs review/refactoring

[CMCDragonkai]

Regarding the COW idea for mutating pulled vaults. I want to point to these relevant links:

• https://dev.to/donovanrichardson/adding-a-new-remote-and-merging-unrelated-branches-1mkm
• https://stackoverflow.com/questions/6286571/are-git-forks-actually-git-clones
• https://stackoverflow.com/questions/36123655/what-is-the-git-alternates-mechanism
• https://git-scm.com/docs/git-worktree
• https://stackoverflow.com/questions/6270193/multiple-working-directories-with-git
• https://stackoverflow.com/questions/25843553/deduplicate-git-forks-on-a-server/52458712

We won't be able to do this feature before release, but we can go into a new epic.

First we have to decide if we are using branches or "forks". I reckon forks makes more sense here, since it's not expected that the changes are merged back to the same git repository or in this case vault. Branches by itself seems to have limited usecase to secrets management, and it's unclear whether there would ever be a need to create a branch for a vault. Unless it was a matter of trying out a different secret but even then this would be strange.

Then once you have a "fork", the opposite would be a "join". One could imagine vault joining which could be useful as a way to merge separate vaults together into one vault.

Note that however forking and joining are sort of one-off operations, history isn't automatically synchronised unlike branches. Since we are expecting zero merge conflicts #172, it eliminating branches and enforcing this COW idea is correct for single vaults. But once you have forked, the ability to auto sync is not possible. And neither is a vault join sort of operation going to create a vault that always updates based on changes of its upstream vaults. But this is something worth testing with respect to secret-management workflows.

[CMCDragonkai]

Done by the merging of vaultsrefactoring: https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205

[CMCDragonkai]

Reference docs to be updated here: https://github.com/MatrixAI/js-polykey/issues/258