Junio C Hamano <gits...@pobox.com> writes: > I looked at the codepath involved, and I do not think that is a > feasible way forward in this case. It is not about a "helpful > message" at all. You would have to do everything that is done in > the error codepath in your custom die routine, which does not make > much sense. > > I think the most sensible regression fix as the first step at this > point is to call it as a separate process, just like the code calls > "apply" as a separate process for each patch. Optimization can come > later when it is shown that it matters---we need to regain > correctness first.
Don't get me wrong by the above, though. I would prefer the endgame to be an efficient implementation of merge_recursive_generic(), a function that you can call without you having to worry about it dying. But the patch in this thread is not that, if I am reading Johannes's description correctly. And by calling merge_recursive_generic() instead of spawning merge-recursive via run_command(), your GSoC series introduced a regression to "am -3". I'd like to see the regression fixed, and spawning merge-recursive is an obviously correct way to do so. That is how "am -3" did it before builtin/am.c after all. Once that is done, the users will not have to worry about this regression, and merge_recursive_generic() implementation can be improved separately. The patch in this thread may serve as a good starting point for that. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
