Re: [PATCH] Try harder to find a remote when on a detached HEAD or non-tracking branch.

[Heiko Voigt <hvoigt@hvoigt.net>]

Hi,

On Tue, Jun 19, 2012 at 10:55:13AM -0700, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> 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