On Thursday 17 June 2010, Junio C Hamano wrote: > 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. Dubious. If Alice's merge of D and F hasn't been properly tested yet, I don't see why it should exist on the submodule's master branch, and if it doesn't, it simply isn't considered, due to Heiko's "stable" branch magic. > 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. Me neither, but after some more thinking I have another alternative as to why the merge G might exist (on the submodule master branch) before the superproject merge is started: If the submodule happens to be maintained as a truly separate project (with its own maintainer), then the maintainer of that submodule may have decided to merge Alice's feature_a branch on its own merits, without looking at the superproject at all. When the superproject maintainer later performs the superproject merge he can just pick up the submodule merge done by the submodule maintainer. But this is pure speculation, and as you say, I'd like to see what workflows Jens and Heiko are actually using. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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