From: Miklos Vajna <vmiklos@frugalware.org>
Date: Mon, 11 Aug 2008 20:45:11 GMT
Subject: Re: [PATCH 2/2] builtin-merge: avoid run_command_v_opt() for recursive
Message-ID: <20080811204511.GV18960@genesis.frugalware.org>
In-Reply-To: <7vvdy7wc8j.fsf@gitster.siamese.dyndns.org>

On Mon, Aug 11, 2008 at 01:03:24PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> 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"?).

atexit() will take care of this. I'll send a testcase for this in a bit,
I just wrote it because I was not exactly sure about this.

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

As far as I see there are no such codepaths, but I may be wrong; in that
case new tests will be needed as well, since the current 'make test'
output is happy. ;-)