Re: Multiple remotes

[Ben Knoble <ben.knoble@gmail.com>]

> Le 25 avr. 2026 à 13:58, Harald Nordgren <haraldnordgren@gmail.com> a écrit :
> 
> 
>> 
>> The last one was a rhetorical question.  I do not want to see such a
>> configuration variable to implicitly trigger fetching at all.
> 
> 🤣
> 
> Good to clarify that when working with me so that I don't go ahead and
> implement that!
> 
>> If you are merely starting at a single arbitrary
>> commit, instead of anticipating to having to repeatedly sync with
>> the remote-tracking branch that will subsequently move, there is no
>> point jumping to a "freshest" commit that you haven't even seen let
>> alone inspected (i.e., you do not even know if it is a good base to
>> build on).
> 
> Not sure I understand this sentiment. For better or worse, the latest
> commit will decide what you have to work with -- unless we expect it to be
> reverted or forced pushed over.
> 
> What better starting point is there?
> 
>> For a starter, if you interact
>> with a repository with two or more branches, should
>> 
>>   $ git checkout --track=fetch -b topic origin/main
>> 
>> update an unrelated remote-tracking branch origin/maint from the
>> same remote?  As I already said, most Git tools _depend_ on the
>> stability of remote-tracking branches
> 
> This is an interesting question, and it's very likely that I am missing
> some nuance here. However, with that said what option does the developer
> have, you have to accept that the upstream changes constantly when others
> are working on it. What good does it do to keep the "head in the sand" any
> longer than necessary?
> 
> I'm not sure there is a way to fetch only 'origin/main' and avoid
> 'origin/maint'? Maybe, maybe, if that exists it could be useful here.

Isn’t that exactly what

    git fetch origin main

does? (Might need to expand the refspec.)

> 
>> still on a leave
> 
> Enjoy your vacation! I don't expect any response from you until you're back!
> 
> 
> Harald
>