Re: git remote set-head automatically

["Bence Ferdinandy" <bence@ferdinandy.com>]

On Wed Nov 20, 2024 at 02:17, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

You learn every day :) I had no idea that the remote's name works this way.

Thanks!

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