Johan Herland <johan@xxxxxxxxxxx> writes: > On Wednesday 16 June 2010, Jens Lehmann wrote: >> Am 16.06.2010 02:05, schrieb Johan Herland: >> > - If the purpose is to re-use existing submodule merges then I'm afraid >> > (as I've argued above) that this would happen too seldom to be useful >> > in practice (and even then you would already have had to set up the >> > appropriate config for your branch, to enable Git to find this >> > pre-existing merge at all). >> >> That this is all but happening seldom for us is the reason for this WIP >> patch from Heiko. And other use cases won't be harmed by this change, no? >> And if some are, we can add a config option to .gitmodules to control >> that. > > Ok. I'm still not sure I see how this can happen frequently in practice, but > since you both probably use submodules more heavily than I do, I will not > stand in the way of progress. At least it would be useful to learn how they manage to often produce the submodule merge G. Your scenario description was very clearly written and in that particular workflow I didn't think it would be plausible to have such a merge before it is needed. IOW, their workflow must be quite different from your scenario description, and I would like to see a plausible scenario description that is as clearly written as yours; perhaps that workflow can even be advertised as one of the BCP. One possibility that comes to mind is perhaps Alice notices the presence of F after she recorded D, merges D and F in the submodule to produce G in the submodule repository, but does _not_ update the superproject to point at it yet, for some reason. Perhaps she hasn't tested the superproject with the merged submodule yet. Whatever the reason is, the tip of her branch in the submodule would be ahead of what her superproject commit D points at, but the commit is available to the maintainer to fetch. Then the maintainer would see G in the submodule (after fetching both superproject and submodule from Alice) already prepared to be used in a merge between D and F. I dunno. -- 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