The best feature of Git is that decentralization is baked right in. upstream is just a label, and one that doesn't come along in a clone. This clean slate of context makes a first class citizen of every single copy of the source code. When you clone a repo, I feel like git should say something like "You now have the ball. What will you do with it?"

As the git/pull request flow becomes the norm, innovation in development process would seem naturally to look toward tooling for forks. How could we make forks interoperate more seamlessly? By perhaps making tools that transplant PRs from one repo to another with higher success.

Is it possible to develop better techniques for merge conflict resolution? I'm sure better understanding of the source of conflict could help.

How could we make package managers more flexible about which fork of a package to link into a stack? Working protocols and API specs seem promising avenues.

· · Web · 0 · 0 · 0
Sign in to participate in the conversation
Ecko /

Creating magic through evolution of the Fediverse. Running Ecko, a community-driven fork of Mastodon managed using the Collective Code Construction Contract (C4) by the Magic Stone Community. C4 is a protocol for asynchronous, non-blocking, distributed, problem-focused software development.