From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 11 Aug 2008 20:03:24 GMT
Subject: Re: [PATCH 2/2] builtin-merge: avoid run_command_v_opt() for recursive
Message-ID: <7vvdy7wc8j.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080811190705.GQ18960@genesis.frugalware.org>

Miklos Vajna <vmiklos@frugalware.org> writes:

> So I don't think there is a case when a die() inside merge-recursive
> would occur, but an other strategy would handle the merge properly.

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.