Re: thoughts on a Merge Request based development workflow

[Dmitry Vyukov <dvyukov@google.com>]

On Thu, Oct 10, 2019 at 9:39 AM Nicolas Belouin
<nicolas.belouin@gandi.net> wrote:
>
> On 10/10/19 1:56 AM, Konstantin Ryabitsev wrote:
> > On Wed, Oct 09, 2019 at 10:21:56PM +0000, Eric Wong wrote:
> >> One of my long-term visions is to have an agreed upon way to
> >> have entirely forkable development communities.  Git already
> >> gave us forkable code repositories.
> > FYI, this does already exist in the form of Fossil:
> > https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
> >
> > The main reason why we can't really consider it is because it requires
> > moving away from git, which is a non-starter for anyone.
> >
> > -K
> Maybe the solution is to build such kind of features within git,
> many proposed solutions with tools over git or using git.
> A tool over git has the issue of conveying the data and making
> it non-centralized, whereas a tool using git is non-scalable because
> of the way git is *currently* storing things.
> Improving git to make it able to store many more objects (be it in-review
> commits or previous versions of patches) and then use it to get the kind
> of features we can envy from fossil.

Hi Nicolas,

I am trying to imagine how a complete solution based on git could look
like, but I am failing. It seems that there is a number of problems
beyond scalability/storage.
First, that git probably should be orthogonal to the kernel source git
trees, right? People work with multiple kernel trees, sometimes
changes migrate, parts of a series can be merged into different trees,
etc.
Then, do we do a single git where everybody has write access, or
per-developer git? If we do a global git and everybody has write
access, this looks somewhat problematic. If we have multiple
per-developer gits, then it does not solve the whole problem of
synchronization and data exchange, one can't pull from thousands of
unknown gits every time.
Where is this git[s] are hosted?
What about force pushes?
What about authorization/user identification?

It would be nice to reuse git's persistent storage format and ability
to push/fetch incremental changes, but we would need to figure out
answers to these questions. Maybe I am missing something obvious.
Could you outline how a solution based on git could look like?
Also in this case git is only a transport layer (like email/SSB), it
won't solve the application layer (how patches/comments/issues/CI
results are described, systems that consume, act and present that,
etc). So building a solid transport, even if we will need to
reimplement some git functionality, will be a smaller part of the
overall effort. And building a solid transport layer that will solve
fundamental infrastructure problems well may be worth it.