Re: [Summit topic] Server-side merge/rebase: needs and wants?
flat view
From: Johannes Schindelin <hidden>
Date: 2021-10-22 10:01:14
Hi Bagas, On Fri, 22 Oct 2021, Bagas Sanjaya wrote:
On 21/10/21 18.56, Johannes Schindelin wrote:quoted
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