Hi, On Tue, Jun 19, 2012 at 10:55:13AM -0700, Junio C Hamano wrote: > Marc Branchaud <marcnarc@xxxxxxxxxxx> writes: > > > On 12-06-18 06:12 PM, Junio C Hamano wrote: > > ... > >> That reliance of "origin" is what made me think that "not guessing > >> and blindly assuming" a wrong thing to do. > > > > I think git can do better than erroring out, though. > > > >> It is OK that your build usesdetached HEAD, but if that is the case > >> shoudln't it be the one deciding which specific remote it wants to > >> take the updated sources from, and telling Git to do so? > > > > Sure, but I feel it did that already when it cloned. It seems reasonable for > > the submodules to default to using the remote specified when the super-repo > > was cloned. > > I do not have a strong opinion either way, other than that I would > prefer predictable behaviour over "works most of the time provided > if the user does X, otherwise does this random thing". And coming > from that standpoint, erroring out when there needs a guess involved > is certainly more predictable---it is a cop-out option for me in > areas of the system I do not have strong preferences. > > If you can work with submodule people (it is good that you Cc'ed > Jens) to come up with a solution to make everything always use > 'origin' when unconfigured in a consistent way, without breaking > existing users who rely on the current behaviour, that would be > good. Or a solution with a predictable behaviour you come up with > may end up being something more involved than "just use 'origin' > when you do not know". As long as the end result can be easily > explained to end users, I wouldn't have any objection. Using the first configured remote as a fallback also sounds quite arbitrary to me. Your current HEAD might have nothing to do with that remote. Before falling back to origin how about guessing the remote from the first branch thats contained in HEAD? To me that sounds quite natural. The first branch could be ambiguous so we would have to come up with some ordering. Maybe a depth search and first parents first? Or a breadth first search with younger generations first and then first parents first? Would that work for your use case Marc? 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