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
