Renamed a branch: get rid of "Heads up!" message

Hello!

I renamed a branch (it was called “main”, now it’s called “public”) on my GitHub repo and whenever I push my changes to the branch I get a warning:

remote:
remote: Heads up! The branch 'main' that you pushed to was renamed to 'public'.
remote:

Things do work out, the code is updated on github, however I would like to get rid of the annoying message. Does anyone know how?

You need to update the upstream branch for the local branch that you’re pushing. It looks like that’s still set to the GitHub main branch.

Assuming the remote for your GitHub repo is called origin and you’re currently on that branch:

git branch -u origin/public

And, I have a similar issue, but originating from a different place. Please refer to GitHub - pete4abw/lrzip-next: Long Range Zip. Updated and Enhanced version of ckolivas' lrzip project. Includes updated SDKs, Filtering, Improved output, ASM Disassembler, and many other features not in the mainline. This is the place to test out new features. .

  1. I had a fork of a repo lrzip. I had the repo “unforked” by github admin
  2. I renamed the repo to lrzip-next

At this point, the master branch was still the same as master in the old source repo. On github I performed the following.

  1. I renamed branch master to old-lrzip
  2. I renamed branch lrzip-next to master

I then cloned the github repo to local repo.

After about a week, when I knew all was well, I deleted the branch old-lrzip first on github and then on my local repo using git branch -D old-lrzip

Even though old-lrzip no longer exists on github or locally, I still get the message

remote: Resolving deltas: 100% (6/6), completed with 6 local objects.
remote: 
remote: Heads up! The branch 'master' that you pushed to was renamed to 'old-lrzip'.
remote: 

when pushing.

This link seemed to have the right answers, but it did not work.

I’m sure I did something out of order and this caused the confusion. @airtower-luna or @ptrxyz any other suggestions? All pushes and tag pushes work fine. The log is up to date properly. The warning seems to mean nothing in terms of functionality. Thank you

Hey there!

The Heads up message feature was introduced as part of the default branch naming transition in 2020. The design behind this functionality was to make the users aware that the default branch had been renamed. So, if the default branch was renamed to main and a push was performed to the old default branch name instead of the new one the message was shown to inform them that they may need to push to the new default branch as well. I have added this to our internal Feature Request List.

We can’t say if/when we may add a feature, however the feedback has definitely been recorded.

2 Likes

Thank you! I too got into a similar situation as the above. Probably due to my mistake. To simplify I have recently done a change similar to the comments above (I believe) like this and got into a similar situation. Essentially a combination of branch renaming, default branch designations, and reusing an old branch from a previous git workflow in a new context.

Here’s an example here at GitHub - shermaneric/test_headsup6

GitHub UI
1. main -> switch default branch to prod

Locally.
git branch -m main prod
git fetch origin
git branch -u origin/prod prod

git checkout main.  # to do more dev work here

git push origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 269 bytes | 269.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Heads up! The branch 'main' that you pushed to was renamed to 'prod'.
remote:
To https://github.com/shermaneric/test_headsup6.git
   f0d0b44..e234721  main -> main
$ ~/Development/test_headsup6 

Like the others, everything “works”. I’ve set my upstream of main to origin/main and HEAD is tracking properly. The git commits are going to the right branches but the heads up slightly takes me off guard :smile:

I totally get it though if this is intended behavior - and reusing old renamed branches for new purposes probably isn’t the best idea. I’m trying to think of a way to rebase my history in a way to avoid this (I’m also trying to repro this) but would rather not spend the calories if at all necessary.

Thanks again!
Eric

Thanks, @jjkennedy3 . Honestly, I can’t claim to fully understand this, especially when the renamed branch is no more. But I do understand that history may preserve links between commits and branches. As @shermaneric said, probably not the best practice to do what we did. But conceptually, making a branch into master or relegating an outdated master or even deleting it should be a feature. In my case, I wanted to be crystal clear that (the former) master was out and a new master was in. In my case, there was no possibility of merging the (new master) branch onto the old master. I had to replace. Thanks again!