[RFC PATCH 0/2] Introduce new merge-tree-ort command

During the 2nd Virtual Git Contributors’ Summit last October, and even before, the subject of performing server side merges and rebases came up, as platforms like GitHub and GitLab would like to support many features and data formats that libgit2 doesn't support, like for example SHA256 hashes and partial clone.

It's hard for them to get rid of libgit2 though, because Git itself doesn't have a good way to support server side merges and rebases, while libgit2 has ways to perform them. Without server side merges and rebases, those platforms would have to launch some kind of checkout, which can be very expensive, before any merge or rebase.

The latest discussions on this topic following the 2nd Virtual Summit[1] ended with some proposals around a `git merge-tree` on steroids that could be a good solution to this issue.

The current `git merge-tree` command though seems to have a number of issues, especially:

  - it's too much related to the old merge recursive strategy which is
    not the default anymore since v2.34.0 and is likely to be
    deprecated over time,

  - it seems to output things in its own special format, which is not
    easy to customize, and which needs special code and logic to parse

To move forward on this, this small RFC patch series introduces a new `git merge-tree-ort` command with the following design:

  - it uses merge-ort's API as is to perform the merge
  
  - it gets back a tree oid and a cleanliness status from merge-ort's
    API and prints them out first

  - it uses diff's API as is to output changed paths and code

  - the diff API, actually diff_tree_oid() is called 3 times: once for
    the diff versus branch1 ("ours"), once for the diff versus branch2
    ("theirs"), and once for the diff versus the base.

Therefore:

  - its code is very simple and very easy to extend and customize, for
    example by passing diff or merge-ort options that the code would
    just pass on to the merge-ort and diff APIs respectively

  - its output can easily be parsed using simple code and existing
    diff parsers

This of course means that merge-tree-ort's output is not backward compatible with merge-tree's output, but it doesn't seem that there is much value in keeping the same output anyway. On the contrary merge-tree's output is likely to hold us back already.

The first patch in the series adds the new command without any test and documentation.

The second patch in the series adds a few tests that let us see how the command's output looks like in different very simple cases.

Of course if this approach is considered valuable, I plan to add some documentation, more tests and very likely a number of options before submitting the next iteration.

I am not sure that it's worth showing the 3 diffs (versus branch1, branch2 and base) by default. Maybe by default no diff at all should be shown and the command should have --branch1 (or --ours), --branch2 (or --theirs) and --base options to ask for such output, but for an RFC patch I thought it would be better to output the 3 diffs so that people get a better idea of the approach this patch series is taking.

[1] https://lore.kernel.org/git/nycvar.QRO.7.76.6.2110211147490.56@tvgsbejvaqbjf.bet/

Christian Couder (2):
  merge-ort: add new merge-tree-ort command
  merge-ort: add t/t4310-merge-tree-ort.sh

 .gitignore                |   1 +
 Makefile                  |   1 +
 builtin.h                 |   1 +
 builtin/merge-tree-ort.c  |  93 ++++++++++++++++++++++
 git.c                     |   1 +
 t/t4310-merge-tree-ort.sh | 162 ++++++++++++++++++++++++++++++++++++++
 6 files changed, 259 insertions(+)
 create mode 100644 builtin/merge-tree-ort.c
 create mode 100755 t/t4310-merge-tree-ort.sh