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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 5823 bytes --]

This session was led by Elijah Newren. Supporting cast: Christian Couder,
Jonathan "jrnieder" Nieder, brian m. carlson, Toon Claes, Orgad Shaneh,
Johannes "Dscho" Schindelin, Derrick Stolee, Philip Oakley, Jeff "Peff"
King, CB Bailey, Ævar Arnfjörð Bjarmason, and Phillip Wood.

Notes:

 1.  https://github.com/git/git/pull/1114

 2.  Not about exposing merge over Git protocol, but about providing plumbing
     for a server to use to run a merge

 3.  Not only merge/rebase, but also cherry-pick, revert

 4.  merge-ORT makes things a bit better, as it doesn’t have some of the
     problems of the recursive algorithm.

 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.

 6.  Use case?

     1.  Currently servers use libgit2 to do these algorithms instead of git
         itself.

     2.  What would it take for us to move the servers off of libgit2 and onto
         Git?

     3.  This would help with a lot of compatibility issues (sha-256, new data
         formats)

     4.  Server cares about the exit code to record the success of the
         operation, including some details around which conflicts happened.

     5.  MUST NOT WRITE A REF in-process (because of replication), so must be
         at a deep plumbing level.

     6.  How to restart the merge once a user has submitted conflict
         resolutions?

     7.  Christian: GitLab also uses libgit2, would like to use C Git. Want to
         not need a worktree for scratch space.

     8.  jrnieder: Write tree with conflict markers and report the conflict
         (just a boolean), at least as an optional mode (JGit does this and
         Gerrit relies on it)

         1. Including when merging binary files, rename conflicts, etc where
            there’s no place to put the conflict markers

     9.  brian: fail-fast mode. Present that a conflict happens very quickly,
         allow conflict marker computation to be done later, upon user request
         or as a background job.

     10. Toon: GitLab would love to use merge ORT, and collaborate on it

     11. Orgad: In case you do have conflicts, does a mergetool-style frontend
         want the three competing versions?

 7.  Dscho: there’s a little-used “git merge-tree” plumbing command

     1. jrnieder: it’s a low-level doesn’t-resolve-conflicts thing, but nothing
        forces us to keep it that way. Intriguing idea

 8.  Difference between rebase and cherry-pick not all that big, apart from
     looking at HEAD (which does not make sense on the server-side)

 9.  --onto already strains the concept of the rebase, should maybe not be
     implicit.

 10. Stolee: Think about future extensibility: e.g., servers might want to
     support --autosquash

 11. It would be nice to rebase multiple, interconnected branches at the same
     time. But how to specify that?

 12. Dscho: I have this problem quite often with my many stacked patch series

 13. I use --recreate-merges (uses “label” command), create refs along the way

 14. Philip: I also rebase with merges and then run a script after the fact to
     update refs

 15. Peff: I do something lower-tech. When I have branches depending on each
     other, I set the upstream config. By doing rebases in the right order, the
     right thing happens.

 16. CB: This feature sounds really exciting, often develops parallel,
     semi-independent changes that only come together in an octopus merge at
     the end

 17. Jonathan: Newcomers sometimes put commits that don’t belong together on
     the same branch; I wish there were a smooth way for them to just “drag
     over” a commit, which we don’t currently have because it involves multiple
     branches. Cheering you on.

 18. cherry-pick in the middle of an interrupted rebase

 19. If we unify them, then this gets messy

 20. Dscho: I’m a strong proponent of being able to cherry-pick while you’re
     rebasing. But I’m also missing the ability to do an interactive rebase in
     the middle of an interactive rebase. I implemented a nested interactive
     rebase in the tooling for Git for Windows, which works by prepending the
     current interactive rebase’s todo

 21. Peff: That works in that context, but is not fully generic (no way to
     --abort / --quit). Would want a stack of operations. I have a command
     called “git continue” that continues whatever operation is in progress.

 22. Once we have every high-level operation pushing / popping like this, that
     kind of thing becomes possible.

 23. Toon: I have that too, also “git abort”

 24. CB: “git abort ” is slightly terrifying, we started with git shell and now
     we have git forth :)

 25. Dscho: could standardize on the git-rebase-todo script and add support for
     other operations, tricky bit would be how to implemented nested commands
     in an abortable fashion

 26. Ævar: would be nice if these are pushable/sharable

 27. Is rebase the right top-level command?

 28. Phillip Wood: for refactoring history, would like a different abstraction
     from rebase

 29. I have a script that does that which works well

 30. jrnieder: https://github.com/arxanas/git-branchless has some non rebase
     based history manipulation helpers as well, can be useful for inspiration

 31. Elijah: I’m thinking of a “git replay” command