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

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> "Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> From: Harald Nordgren <haraldnordgren@gmail.com>
>>
>> Add a --fetch option to git checkout and git switch, plus a
>> checkout.autoFetch config to enable it by default. When set and the
>> start-point argument names a configured remote (either bare, like
>> "origin", or prefixed, like "origin/foo"), fetch that remote before
>> resolving the ref. Aborts the checkout if the fetch fails.
>>
>> Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>
>> ---
>
> It is true that "checkout" does funny things to special case the
> remote-tracking branches, like setting up the branch.<name>.merge
> configuration or even inferring the name of the local branch to be
> created.  
> ...
> ...  Should the configuration cause a fetch to happen before any
> of these uses of remote-tracking branches for consistency?

The last one was a rhetorical question.  I do not want to see such a
configuration variable to implicitly trigger fetching at all.

I am somewhat sympathetic to the desire "I want to be sure that I
start the new branch in a state as fresh as possible".  It is tied
to the "--track" option of "git checkout -b topic --track
origin/main".  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).

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.  And extend branch.autosetup{Merge,Rebase}
that controls what happens when a branch is created with "checkout
-t -b" or "branch --track" so that the remote-tracking branch gets
updated, perhaps.

As to "git checkout origin/main" (nothing else on the command line),
it has "magic" compared to "git checkout origin/main~0" already by
treating the parameter not just as a SHA-1 expression that names a
commit object but as a remote-tracking branch (this is necessary for
"-t").  So I am not fundamentally opposed to the idea to give an
option to treat that form specifically.

Having said all that, quite honestly, I prefer not to see any of the
above changes, including the original patch.  It leaves too many
usability questions unaddressed.  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---the desire to update the
origin/main when a new branch that builds on origin/main is created
may be a valid one, but it is unclear if that warrants updating
other remote-tracking branches only because they come from the same
remote repository.  There may be a dozen other UI/usability issues
that will be introduced if we start to "fetch from remote"
automatically, but I won't even try to be exhaustive while I am
still on a leave ;-)