On Fri, Nov 20, 2020 at 07:18:39PM -0600, Felipe Contreras wrote: > On Fri, Nov 20, 2020 at 6:40 PM Jeff King <peff@xxxxxxxx> wrote: > > > I don't think we do advertise the symref in such a case. In v2, the > > symref information is attached to individual lines in the ref > > advertisement. And we don't advertise the unborn line (we could, but I > > think we might need a special syntax for the oid field). > > This may be worth considering changing. I agree it might be nice, but may not be worth the effort (it will require a protocol extension). However... > If a hosting provider (e.g. GitHub) decides to configure an initial > branch (e.g. main) it would be nice for "git clone" to have > information about that initial branch so the user doesn't have to > change it manually to please the provider's aesthetics. > > So the instructions could be: > > git clone $url . > echo "# myproject" >> README.md > git add README.md > git commit -m "first commit" > # git branch -M main # this step would not be necessary > git push -u origin HEAD > > Personally I don't care about this. But others might find it useful. I don't think you have to do the rename here if you don't want to. If there is already content on the "main" branch at GitHub, then clone should pick that as the default branch for your local clone. If there isn't, then you'll get whatever your local git-clone decides on. But when you push, at least to GitHub, if the server-side HEAD points to an unborn branch, it will re-point to the newly pushed branch. So with the current version of Git, you would end up with "master" on the remote side. And that should continue to work as it always has (AFAIK any changes on GitHub's side are purely about default branch names, such as when you add template files as part of the repo initialization). Of course if you _want_ "main" in both cases, you'd have to rename the branch. But you would probably set init.defaultBranch in that case. -Peff
