On Mon, Aug 03, 2020 at 12:00:51PM -0400, Taylor Blau wrote: > This is more-or-less what I was proposing in the message that I linked > above. Maybe a more solidified proposal might look something as follows: > > - We could introduce a mechanism to mark certain refs as aliases to > other refs. For example, a remote might publish its > 'refs/heads/master' as an alias to 'refs/heads/main', so that any > reads or writes to the former get applied to the latter > transparently. I think symrefs do this already. Try this: git init parent git -C parent checkout -b main git -C parent commit --allow-empty -m one git -C parent symbolic-ref refs/heads/master refs/heads/main git clone parent clone cd clone GIT_TRACE_PACKET=1 git ls-remote 2>&1 >/dev/null | perl -lne '/git</ && /packet: (.*)/ and print $1' Assuming you have the v2 protocol enabled, you should see: git< 3ba9220cd714e9350cb4becd1cb56d0cacf29d9b HEAD symref-target:refs/heads/main git< 3ba9220cd714e9350cb4becd1cb56d0cacf29d9b refs/heads/main git< 3ba9220cd714e9350cb4becd1cb56d0cacf29d9b refs/heads/master symref-target:refs/heads/main (if you don't you'll still see them as aliases, but you won't be told that master is a symref). And it even works for pushing. Doing: git checkout -b master origin/master git commit --allow-empty -m two git push updates both "main" and "master". The real trick is that you can't create or update symbolic refs on the server side using a client. So this would have to be something that hosting providers allow (and there might be some security implications; I'm not sure what happens if you create a loop in the symref resolution). > - A ref alias can be annotated to say "I am a transition ref alias", > i.e., that clients should be taught to rename their copy of 'master' > to 'main' (and update remote-tracking refs accordingly). It's not specifically marked as a transition, but a client could act on the symref advertisement above. -Peff
