Hi,
this comes after a bit of discussion on #git. The current behaviour of git is
that when cloning, `refs/remotes/[remote]/HEAD` is set, but if you use `git
init` and `git remote add`, then you must manually run `git remote set-head -a`
to arrive at the same state. Having origin/HEAD set is pretty useful for
scripting and aliases, because you don't need to remember what the current
project uses (origin/[master|main|trunk|etc]).
I would propose that running `git fetch` should also update remote/HEAD. In
case there is a possibility that it is useful in some cases that remote/HEAD is
actually different from whatever is set in the remote repository as the default
branch, I think a setting for opt-out would be better, and the default
behaviour should be essentially always running `set-head -a`.
My current workaround is an alias:
fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}
which works for me, but I think it would be more elegant not to have to do this.
A slight aside: if `refs/remotes/[remote]/HEAD` is set you still might have
a problem of easily accessing the current remote's HEAD, since @{upstream} will
point to the branch. It's again not something you can't script around, but
would be cool if there were an easy way of avoiding hardcoded "origin" in
aliases and scripts.
Thanks for considering!
Best,
Bence
