Hi, On Thu, May 12, 2011 at 1:44 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Jonathan Nieder wrote: >> Christian Couder wrote: > >>> I think that the risk at this point might be to overengineer things >>> and to lose time, and then we will perhaps find out that we need to do >>> some refactoring of the merge_recursive API anyway. >> >> I agree with the general principle... let's see if I understand the >> details of what you are saying. > > It occurs to me now that you were probably talking about the > suggestion of using the lockfile API (i.e., the write temporary/rename > trick). In that case, I agree --- no need to overengineer it and > concurrency problems can be fixed later. Sorry for an overcomplicated > explanation. Yeah, it was mostly the lockfile API. About writing files before each cherry-pick, I am not against it, if it is really needed to be safe. I even suggested it in my patch series back in November (http://article.gmane.org/gmane.comp.version-control.git/162183). But it will make cherry-pick less efficient, so it is a kind of performance regression that we can perhaps avoid by changing some die() into error(). So what i suggest and in fact started is to just try that. We may find that we could indeed do it quite safely or we may find that it's too much work to be safe enough. When I tried it, it seemed to me that it was not a lot of work, and not very complex, though it added many commits to the patch series. But perhaps I overlooked some problems. I will have another look soon. Thanks, Christian. -- 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