Jeff King <p...@peff.net> writes: > On Tue, Sep 24, 2019 at 04:25:45PM +0200, Johannes Schindelin wrote: > >> > 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. > > OK, great, then we are completely on the same page. :)
I wondered briefly if we want tospecial case the string 'git-merge-one-file' (iow, teaching merge-index a new option "--use-builtin-merge-one-file" and update our own use in git-merge-octopus.sh, git-merge-resolve.sh, etc. would be safer). But "git merge-index git-merge-one-file" called in the context of scrpted Porcelain has the directory that has *OUR* git-merge-one-file as the first element on $PATH, I think, so it may be perfectly safe to use the "ah, the command name we are asked to run happens to be git-merge-one-file, so let's use the internal version instead without spawning" short-cut.
