Re: [PATCH 2/2] builtin-merge: avoid run_command_v_opt() for recursive

Miklos Vajna <vmiklos@frugalware.org> writes:

Normal case is fine.

I was not worried too much about "the other strategy will" case, but isn't the general structure of git-merge driver be:

    - do some set-up computation, and leave info in .git/
    - call strategy
    - depending on how it exits, perform further operation (such as
      writing out tree out of index and updating HEAD) using the info in
      .git it left before it called strategy, and clean up whatever was
      done in the first step (things like "drop the index lock"?).

Dying in the strategy and not allowing the clean-up was what I was worried about. If you can guarantee that you are not going to leave the repository in a wedged state, calling merge-recursive internally is perfectly fine, but the codepaths involved need to be carefully vetted for that.