Re: Suggestion: Real-time or Conflict-Reducing Collaboration Support for Specific Directories
Show 5 quoted lines
> However, I have also encountered a recurring difficulty in daily use. For certain types of files, especially files under script directories or other frequently modified directories, conflicts happen quite often because updates are not synchronized in real time. In some project scenarios, multiple engineers may edit related scripts at the same time, and this can lead to repeated merge conflicts and extra coordination costs.
>
> I wonder whether Git could provide, in future versions, some optional features similar to online collaborative documents, or directory-level collaboration mechanisms for specific files or folders. For example, users could enable special real-time update, lock, notification, or conflict-reduction behavior for selected directories such as scripts. This could help reduce conflicts and make Git even more convenient for teams working on highly shared files.
>
> I understand that Git is designed as a distributed version control system, and such functionality may not be simple to implement. Still, I believe an optional feature in this direction could be very helpful for many engineering teams.
First I don't think it's Git's role to provide a full collaborative editor, but you are right that it could provide mechanisms that could help.
Then there are a number of features/mechanisms that other SCMs or tools provide that could perhaps help:
- Jujutsu's working copy as a commit
(https://docs.jj-vcs.dev/latest/working-copy/)
It could help write a background script that constantly pushes and rebases the current commit to a shared server as the user types, mimicking a real-time sync.
Jujutsu's first-class conflicts could perhaps help too.
- Pijul's CRDTs and the Theory of Patches (https://pijul.org/manual/theory.html)
To seamlessly merge real-time changes without locking the file or constantly throwing conflict errors, modern collaborative editors abandon SCM snapshot merging entirely. Instead, they use one of two mathematical models:
- Operational Transformation (OT): Used by Google Docs.
- Conflict-free Replicated Data Types (CRDTs): Used by newer tools
like Figma, Zed, and Apple Notes.
Pijul's underlying Rust library (libpijul) which already uses CRDTs could be wrapped and adapted to fit a real-time context.
- Michael Haggerty’s `git-imerge`
(https://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html)
I think this is the right way to simplify complex merges and rebases as much as possible, which is useful if a lot of such operations have to be made.
- CRDT AST (https://github.com/aaronmunsters/AST_CRDT)
- Automerge (https://automerge.org/docs/hello/)
- Yjs (https://github.com/yjs/yjs)
It would be indeed complex to implement any of these in Git.
The nice thing if someone would want to implement backend collaborative editing features is that these days an AI could perhaps resolve merge conflicts automatically. (But of course users should have a way to override the AI's decisions if they think it's wrong.) There are already a number of tools out there doing that for regular development.
Best, Christian.