On Wed, Aug 24, 2011 at 12:24:22PM -0700, Junio C Hamano wrote: > Heiko Voigt <hvoigt@xxxxxxxxxx> writes: > > > ... Its a > > little bit workaroundish so if anymore has an idea how to fix this in > > nicer way, please tell me. > > > > [1]--8<---- > > From: Heiko Voigt <hvoigt@xxxxxxxxxx> > > Subject: [PATCH] protect submodule merge search against multiple calls for > > the same path > > > > When multiple merge-bases are found for two commits to be merged the > > merge machinery will ask twice for a merge resolution. Currently its not > > possible to use the revision-walking api for walking the same commits > > multiple times. > > I have been suspecting that most of this should be done in a separate > helper program that is run via run_command() interface, without > contaminating the object pool the main merge process has with data from > the submodule object store to begin with (i.e. add_submodule_odb() and > everything below should go). Wouldn't it be a lot cleaner solution? Hmm, I would like to keep it in process. Since there are platforms where spawning new processes is very slow. If just the revision-walking is an issue: I am currently working on extending it to be able to walk again, because we also need that for the recursive push series. But even if we are able to search twice or more (in or out process) we would give the advice that there are multiple possible resolutions for each merge base. For the merge search we do not take the bases into account so the outcome will not change. So what I think would be cleaner (also UI wise) is to remember whether we already gave advice and not do it a second time. Cheers Heiko -- 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