Re: Git in Outreachy December 2019?

From: Jeff King <peff@peff.net>
Date: Sep 23, 2019, 18:07 UTC
Message-ID: <20190923180751.GA21344@sigill.intra.peff.net>
In-Reply-To: <nycvar.QRO.7.76.6.1909171158090.15067@tvgsbejvaqbjf.bet>

On Tue, Sep 17, 2019 at 01:23:18PM +0200, Johannes Schindelin wrote:

Show 6 quoted lines

> 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.

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.