Re: [PATCH] remote: add --set-head option to 'git remote add'

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

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Harald Nordgren <haraldnordgren@gmail.com>
>
> Mirror the behavior 'git clone' applies to its first remote: after
> fetching, set refs/remotes/<name>/HEAD to the remote's default branch.
>
> Equivalent to running:
>
>     git remote add -f <name> <url>
>     git remote set-head <name> -a
>
> The new option implies --fetch.

Should this option (and the auto mode of "git remote set-head") even
be necessary as an extra thing that the end-user should need to be
aware of these days?

It feels to me that the "fetch" part of "git remote add --fetch"
command should behave in line with what "git fetch" from the remote
does with "remote.<name>.followRemoteHEAD" configuration.

Of course, the current implementation may not do so, and that is why
you are sending this patch.  A patch would need to plumb through the
mechanism, but I think this should be pretty much automatic without
giving more control than what the users already have.

And because remote.<name>.followRemoteHEAD that is unconfigured is
the same as setting it to "create", it means "git remote add -f"
will behave just like "git clone" would to remember the upstream
choice of which of their branches is the primary one (which is what
HEAD in the publishing repository means), unless the variable is
explicitly configured to "never".

IOW, I think this should/can be done as a bugfix, i.e.,

    Even though "git clone -o <name> <URL>" does, "git remote add
    --fetch <name> <URL>" does not create refs/remotes/<name>/HEAD.

    Fix it by making it honor the remote.<name>.followRemoteHEAD
    configuration variable, which was invented exactly for this
    purpose..

or something.