Hi Dscho, On Fri, Jul 26, 2019 at 4:25 AM Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > On Thu, 25 Jul 2019, Elijah Newren wrote: > > > On Thu, Jul 25, 2019 at 1:12 PM Johannes Schindelin > > <Johannes.Schindelin@xxxxxx> wrote: > > But, more importantly: > > * I want to write an alternative merge strategy providing drop-in > > replacement functions for merge_trees(), merge_recursive(), and > > merge_recursive_generic(). Defining merge_options_internal inside > > merge-recursive.h would mean that I have to have _exactly_ the same > > internal options in my implementation of merge-ort.c. That doesn't > > make sense. > > Fair enough. > > I'm curious: what merge strategy are you planning on implementing? recursive, done right[1]. For now, I'm calling it "Ostensibly Recursive's Twin", or "ort" for short. At first, people shouldn't be able to notice any difference between it and the current recursive strategy, other than the fact that I think I can make it a bit faster (especially for big repos). But it should allow me to fix some (admittedly corner case) bugs that are harder to handle in the current design, and I think that a merge that doesn't touch $GIT_WORK_TREE or $GIT_INDEX_FILE will allow for some fun new features. That's the hope anyway. [1] https://public-inbox.org/git/xmqqd147kpdm.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/
