Thread (50 messages) 50 messages, 15 authors, 2021-11-30

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help