Multiple remotes

From: Harald Nordgren <haraldnordgren@gmail.com>
Date: Apr 25, 2026, 17:58 UTC
Message-ID: <20260425175824.48380-1-haraldnordgren@gmail.com>
In-Reply-To: <xmqqfr4jwxzi.fsf@gitster.g>

> 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!

Show 6 quoted lines

> 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?

Show 8 quoted lines

> 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.

> still on a leave

Enjoy your vacation! I don't expect any response from you until you're back!

Harald