On Mon, Aug 9, 2021 at 10:38 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
...
> > === Extensibility ===
> >
> > Being able to perform merges without touching the working tree or index
> > makes it possible to create new features that were difficult with the
> > old backend:
> >
> > * Merging, cherry-picking, rebasing, reverting in bare repositories...
> > or just on branches that aren't checked out.
>
> Rebasing without updating the worktree for each commit is exciting.
Yeah, there appear to be some interesting twists from my initial
investigations so far. I may need to start some interesting
discussions in the next cycle or two about what we should do here (and
also for merges in bare repositories.)
> I agree with others that this should be merged into next sooner rather
> than later. I also agree with Peff's point about moving it into master
> to get more people using it rather than sitting in next for too long.
:-)
> I think the sequencer changes below are easier to follow in this
> version.
Thanks for taking a look.
> One thing I did wonder is whether there needs to be any change
> to the CI scripts to ensure we keep testing both merge implementations.
There did need to be such a change, but it was made previously in
commit f3b964a07e ("Add testing with merge-ort merge strategy",
2021-03-20). That commit changed the default merge backend *for
testing* to be merge-ort, and modified the linux-gcc job to explicitly
specify recursive. This commit doesn't change the testing story, so
the recursive backend will still continue to be tested with the
linux-gcc tests, or whenever someone requests it with
GIT_TEST_MERGE_ALGORITHM=recursive, and otherwise merge-ort will be
used.
> Best wishes and congratulations on an impressive achievement
Thanks!
