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