On Tue, Nov 17, 2020 at 06:18:03PM -0600, Felipe Contreras wrote: > On Tue, Nov 17, 2020 at 5:33 PM Jeff King <peff@xxxxxxxx> wrote: > > On Tue, Nov 17, 2020 at 04:47:56PM -0600, Felipe Contreras wrote: > > > > This should be easy to do if we make "origin" be a pseudo ref that > > > points to "origin/HEAD" (and we could introduce "origin/@"). > > > > Didn't we already do this long ago? refs/remotes/%s/HEAD is special in > > the dwim_ref() lookup: > > > > $ git rev-parse --symbolic-full-name origin > > refs/remotes/origin/master > > Hmmm. For some reason none of my remotes do have a HEAD. > > If I do "git remote add", and then fetch, the HEAD doesn't seem to be present. Yes, I have run into that, and it's definitely annoying. The refs/remotes/<remote>/HEAD symref is created by clone, but is not updated by "fetch". That's intentional, because it's supposed to represent a local choice (that is merely seeded by the remote side). But it seems like adding it if it's missing might be reasonable. I'm not sure if "git remote add" should be doing it (it already can do it with "git remote set-head -a", but that is not the default when adding a new remote, which otherwise does not contact the network at all). Or if "git fetch" should be doing it. Certainly having "fetch --update-remote-head" would be fine, but that doesn't really solve the problem (which is that people don't realize they need to specify it). There was some related discussion in: https://lore.kernel.org/git/CAEXP2g8-reK+u2FaO=mMP-nsvuDDWGpwV_tyKG5L5XpU=1LQeg@xxxxxxxxxxxxxx/ but I don't think any patches came out of that. -Peff
