Re: [PATCH] checkout: add --fetch to fetch remote before resolving start-point

[Harald Nordgren <haraldnordgren@gmail.com>]

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