From: Harald Nordgren Date: Tue, 28 Apr 2026 08:44:15 GMT Subject: Re: [PATCH] checkout: add --fetch to fetch remote before resolving start-point Message-ID: <20260428084415.10702-1-haraldnordgren@gmail.com> In-Reply-To: I hope you had a good leave and is back with renewed energy! ☀️ > Git is among projects that encourage forking only from a well-known > point in history (like the latest released version), not at a random > "tip of the day" commit from the upstream. Are you talking about the Git project that we are working on right now, or talking about how people use Git "in the wild"? Because how people use Git in the wild can be a bit different, and merge conflicts arguably the worst part of collaborating with a team using Git. In my early days as a professional coder, snubbed my toe countless times on forgetting to pull in the latest changes, before starting to work on something. I respect that things work differently in a neatly ordered project like Git itself, where you do a great work of organizing, but all other projects are not like that. My advice to a junior developer is to pull in the latest changes when starting and to rebase obsessively to prevent a large merge conflict down the road. > So instead of introducing a totally new option that can only be used > only when "--track" is given, it might make more sense to introduce > this as a variant of "--track", perhaps "--track=fetch,[in]direct" > or something like that. > I may have already pointed this out (but I do not remember), but > this option would not make any sense when --track is not in effect, > so instead of adding a brand new option, making it an extension to > the existing --track option might make it slightly more palatable. Fair enough. You did point it out and I will give that a try! Harald