On 12-06-19 04:12 PM, Jeff King wrote: > 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. > > One thing that makes me nervous about this patch is that it is not just a > change to git-submodule, but rather to git-parse-remote. So it could > affect other parts of the system, too, where a guess might not be as > desirable. > > The number of affected code paths is fortunately quite small, since this > is updating the shell library, and most of the remote-handling code is > written in C these days. But it raises a few questions: > > 1. git-pull can call into get_default_remote via get_remote_merge_branch. > Is it impacted by this change? I imagine it is. > 2. We install git-parse-remote as part of the plumbing API. Do we know > of any other 3rd-party scripts that use this interface and might be > affected? I certainly don't know of any. > 3. The C code sets up remote.c:default_remote_name, which defaults to > "origin". Should this be consistent with what git-parse-remote > does? Yes, I think it should. I think you're raising some good points, but I'm not in a good position to evaluate the impacts on git-pull or 3rd-party apps. I suggest git would be better off changing the way it finds the default remote to: Use the currently checked-out branch's remote; or Use the remote specified in the original clone command[*]; or use "origin". [*] With some strong mechanism for identifying this remote. I think this would make the default-remote concept work properly in more cases, while still maintaining compatibility with current assumptions (because folks who are happy with the arbitrary choice of "origin" probably never used -o in their clone commands anyway). I'd be fine with erroring-out (or just having no default remote) instead of using "origin", but I suspect that would cause more headaches than it solves. I'm happy to cobble together a patch, if we agree to move in this direction. M. -- 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