@mellowagain and I have been discussing making merge/pull requests as extension types within the git-bug spec. The idea is that since git-bug is already designed to be fully decentralized and extensible, it would be relatively easy to store the necessary information within git-bug's database. There are at least two advantages to this:
- No need to come up with a separate synchronization protocol like in ForgeFed; git itself is the server. It also means that if git develops new ways of moving data around, 'git-bug-spec' compliant implementations get that power for free.
- Part of git's superpower is that it is fully decentralized; this is extremely useful if your team is partitioned for a time. E.g., if half the team is in the cut off in the field somewhere, while the other half is in the office, both sides continue to work without pause. Once they rejoin, git-bug's CRDT-based merge will ensure everyone has the merge requests queued up and available.
Making this possible does require developing a spec for merge/pull requests. This will need to be done after the current spec is cleaned up.
@mellowagain and I have been discussing making merge/pull requests as extension types within the git-bug spec. The idea is that since git-bug is already designed to be fully decentralized and extensible, it would be relatively easy to store the necessary information within git-bug's database. There are at least two advantages to this:
Making this possible does require developing a spec for merge/pull requests. This will need to be done after the current spec is cleaned up.