Hi Peff, On Mon, 23 Sep 2019, Jeff King wrote:
> On Tue, Sep 17, 2019 at 01:23:18PM +0200, Johannes Schindelin wrote: > > > The only slightly challenging aspect might be that `merge-one-file` is > > actually not a merge strategy, but it is used as helper to be passed to > > `git merge-index` via the `-o <helper>` option, which makes it slightly > > awkward to be implemented as a built-in. A better approach would > > therefore be to special-case this value in `merge-index` and execute the > > C code directly, without the detour of spawning a built-in. > > I think it could make sense for merge-index to be able to directly run > the merge-one-file code[1]. But I think we'd want to keep its ability to > run an arbitrary script, and for people to call merge-one-file > separately, since right now you can do: > > git merge-index my-script > > and have "my-script" do some processing of its own, then hand off more > work to merge-one-file. Oh, sorry, I did not mean to say that we should do away with this at all! Rather, I meant to say that `merge-index` could detect when it was asked to run `git-merge-one-file` and re-route to internal code instead of spawning a process. If any other script/program was specified, it should be spawned off, just like it is done today. Thanks, Dscho > So the weird calling convention is actually a user-visible and > potentially useful interface. So it would need a deprecation period > before being removed. > > -Peff > > [1] Certainly doing it in-process would be faster for the common case of > "git merge-index git-merge-one-file", but I wonder if anybody really > does that. These days most people would just merge-recursive anyway. >
