On Mon, Aug 11, 2008 at 01:03:24PM -0700, Junio C Hamano <gitster@xxxxxxxxx> 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. ;-)
Attachment:
pgp9TmW5CnaLp.pgp
Description: PGP signature
