Hi Bagas, On Fri, 22 Oct 2021, Bagas Sanjaya wrote: > 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
