Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
