git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Marc Branchaud <marcnarc@xiplink.com>
Date
Jun 19, 2012, 21:42 UTC
Message-ID
<4FE0F262.9050404@xiplink.com>
In-Reply-To
<20120619193114.GA461@book.hvoigt.net>
On 12-06-19 03:31 PM, Heiko Voigt wrote:
Show 39 quoted lines
> 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.

Sure, but if it doesn't specify a remote then why not? (Instead of "first configured remote" think "remote used in the initial clone command".)

Show 7 quoted lines
> 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?

This sounds much harder to explain to a user than "the remote you used when you cloned the repo".

> Would that work for your use case Marc?
Maybe, but it seems much more complicated than necessary.
		M.
Previous: Heiko VoigtNext: Heiko Voigt
Message 8 of 20 in “Try harder to find a remote when on a detached HEAD or non-tracking branch.”
  1. Try harder to find a remote when on a detached HEAD or non-tracking branch.marcnarc@xiplink.com, Jun 18, 2012
  2. Junio C HamanoJun 18, 2012
  3. Marc BranchaudJun 18, 2012
  4. Junio C HamanoJun 18, 2012
  5. Marc BranchaudJun 19, 2012
  6. Junio C HamanoJun 19, 2012
  7. Heiko VoigtJun 19, 2012
  8. Marc BranchaudJun 19, 2012
  9. Heiko VoigtJun 20, 2012
  10. Jeff KingJun 19, 2012
  11. Junio C HamanoJun 19, 2012
  12. Marc BranchaudJun 19, 2012
  13. Jeff KingJun 19, 2012
  14. Junio C HamanoJun 19, 2012
  15. Jeff KingJun 19, 2012
  16. Junio C HamanoJun 19, 2012
  17. Jens LehmannJun 19, 2012
  18. Marc BranchaudJun 19, 2012
  19. Phil HordJun 20, 2012
  20. Arnaud LacombeJun 18, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.