From: Ben Knoble Date: Sat, 25 Apr 2026 21:57:25 GMT Subject: Re: Multiple remotes Message-ID: In-Reply-To: <20260425175824.48380-1-haraldnordgren@gmail.com> > Le 25 avr. 2026 à 13:58, Harald Nordgren 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 >