Re: [Summit topic] Server-side merge/rebase: needs and wants?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 22, 2021, 10:01 UTC
Message-ID: <nycvar.QRO.7.76.6.2110221155460.62@tvgsbejvaqbjf.bet>
In-Reply-To: <bdf47d51-9cf6-046d-fd97-aa35299daadd@gmail.com>

Hi Bagas,

On Fri, 22 Oct 2021, Bagas Sanjaya wrote:

Show 14 quoted lines

> On 21/10/21 18.56, Johannes Schindelin wrote:
> >   5.  The challenge is not necessarily the technical challenges, but the UX
> >   for
> >       server tools that live “above” the git executable.
> >
> >       1. What kind of output is needed? Machine-readable error messages?
> >
> >       2. What Git objects must be created: a tree? A commit?
> >
> >       3. How to handle, report, and store conflicts? Index is not typically
> >          available on the server.
>
> 1) I prefer human-readable (i.e. l10n-able) output, because the output
> messages for server-side merge/rebase are user-facing.

For server-side usage, a human-readable output _by Git_ would not make sense. It would be the responsibility of the server-side caller (which is usually a web application) to present the result, potentially translated, definitely prettified.

So while I agree with you that the result should be made pretty on the server side, I disagree that this is Git's job. Instead, Git should produce something eminently machine-parseable in this context.

> 2) Same as when doing merge/rebase on local machine (merge commit if non-ff).

Local usage is _totally_ different.

> 3) I think because on the server-side we have bare repo (instead of normal
> repo), we need to create temporary index just for merge/rebase.

Merge ORT does not need a temporary index. That's the reason it is so much faster than the regular merge-recursive.

> For conflicts, the users need to resolve them locally, then notify the
> server that they have been resolved, and continue merging process.

It is already possible e.g. on GitHub to resolve merge conflicts in the web UI. That is very convenient, and I think we all agreed at the Summit that this is a scenario Git should support as well as it can. We did not come to any concrete conclusion how that should look like (read: what output format Git could use to support server-side consumption better), though, and I think it basically comes down to experimenting with a couple approaches.

Ciao, Dscho