On Mon, Feb 21, 2022 at 1:06 AM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > Hi, > > On Thu, 3 Feb 2022, Elijah Newren wrote: [...] > > I agree. I've got a lot of thoughts on it, and some work in progress > > towards it (https://github.com/newren/git/tree/replay -- _very_ hacky, > > not even close to alpha quality, lots of fixup commits, todo comments, > > random brain dump files added to the tree, based on a previous round > > of this patch series, not updated for weeks, etc., etc.) > > Just chiming in that I find that very exciting. But it's a tangent, and > slightly distracting from the topic at hand, so I would like to ask to > focus back on server-side merges. +1 for refocusing. > > We'll certainly have discussions on what that should look like. But a > > plumbing-ish replacement for merge was much simpler, and made sense to > > do first. I would prefer to concentrate on getting that hammered down > > first. Then I'll start discussions on a plumbing-ish > > rebase/cherry-pick. And if that doesn't fulfill all the needs that > > folks think they want out of merge-tree, then we can add a > > merge_incore_nonrecursive()-based mode to merge-tree. It's all > > coming, but having fought transliterations-of-scripts in > > merge-recursive.c, sequencer.c, stash.c, rebase.c, etc. for years I > > really, really don't want any more of that. Let's end that insanity. > > Being the driving force behind many a "built-in-ification" of scripted > commands, I wholeheartedly agree. You can still see the fall-out of > designing commands in a scripted fashion, without any way to represent > data structures other than strings. I wish we had come up with a better > design to prototype commands than to write shell scripts. But I have to > admit that even I do not have any better idea than to work on a proper API > for libgit.a (which has historically invariably seen push-back from > Junio). > > While I agree that this discussion is a valuable one, right now I would > like to focus on getting the server-side merges done, and once that has > happened, move on to the replay/sequencer/API discussion (which will > probably be a big one, not so much for technical reasons but more for all > too human ones). I'm just guessing, but I suspect your prediction for the future replay/sequencer/rebase/API discussion will be spot on. :-)
