Re: git remote set-head automatically

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

Caleb Cushing <xenoterracide@gmail.com> writes:

> sounds great. I think I realized why I didn't have it. It's not done
> by `git remote add <origin> https://...`  my experiment was `git
> remote rm origin` and then `git remote add origin ... ; git fetch
> --all --prune` I think I also tried without the prune option. git
> version 2.46.1

Yes, "git fetch" does not notice a missing remotes/$name/HEAD and
does not automatically create it.

This is being worked on in a separate thread.

Doing it unconditionally may hurt some existing users (including me)
who see more than one primarily interesting branches in a single
remote and want to force themselves to be more explicit, though.
For us, leaving remotes/$name/HEAD missing (e.g. by "git clone"
followed by "git update-ref --no-deref -d refs/remotes/origin/HEAD")
is a way to allow ourselves to say things like

    $ git checkout -b mytopic origin/maint
    $ git rebase origin/master mytopic

but not

    $ git checkout --detach origin

because the last one is ambiguous between the two branches of
primary interest.

But hopefully they have trained their fingers not to say "origin" by
now ;-) So changing "git fetch" to auto-fill remotes/origin/HEAD to
whatever branch the remote is pointing at at the time of running
would be good enough for an initial enhanced version, even though we
might need to further improve on by allowing folks to opt out of the
feature.