Multiple remotes

[Harald Nordgren <haraldnordgren@gmail.com>]

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

> still on a leave

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


Harald