Re: git remote set-head automatically

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 20, 2024, 01:17 UTC
Message-ID: <xmqqv7wiaeku.fsf@gitster.g>
In-Reply-To: <CAAHKNRF8JDUTH-QzPG1b4-wafzU+MXaMNinfBRu3JfCssfwGUw@mail.gmail.com>

Caleb Cushing <xenoterracide@gmail.com> writes:

Show 5 quoted lines

> 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.