8

After running a bunch of commands trying to create and delete tags and branches, I see the following

enter image description here

What is it, and how should I handle it?

(Edited out content that turned out to be irrelevant)

OverLordGoldDragon
  • 1
  • 9
  • 53
  • 101
  • 1
    Git itself has no notion of "protected" branches. It's a GitHub feature, and something you need to enable via GitHub (either the website or their API). Possibly unrelated, but you should *not* be using things like `push -f` unless you know what they are doing; don't just add them to see if they make an error go away. – chepner Jul 16 '22 at 14:33
  • @chepner I figured maybe it's a built-in alarm for when someone's forcefully deleting stuff, but I'd like to be sure. Also, I'm sure you're right on `-f`, but I'll keep doing it - at least as long as it says so in an SO answer. – OverLordGoldDragon Jul 16 '22 at 14:52
  • https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches – matt Jul 16 '22 at 15:03
  • 1
    My guess is that GitHub is responding to your use of force pushing, which is exactly the sort of thing that a protected branch prohibits. You really ought to learn enough about Git and GitHub to know what you are doing when you do things. – matt Jul 16 '22 at 15:04
  • @OverLordGoldDragon *I figured maybe it's a built-in alarm for when someone's forcefully deleting stuff,* No, that's **not** what it is. Force pushing is **incredibly dangerous** and shouldn't be something you use without understanding exactly what it does, and when and why you should be using it. – Daniel Mann Jul 16 '22 at 16:16
  • @DanielMann If that's not what it is, then what is it? The rest of the comment doesn't specify, and I don't know if "it's not this" can be believably said without "it's this instead". – OverLordGoldDragon Jul 16 '22 at 16:45
  • @OverLordGoldDragon It's easy to find plenty of [references](https://stackoverflow.com/questions/43567577/what-is-the-different-between-force-push-and-normal-push-in-git) that explain it. Force pushing **replaces** the remote repo's history with *your* local copy. Meaning that you can destroy the work of others. It *can* be recovered from when it happens, but it's much easier to just not get into that situation in the first place. – Daniel Mann Jul 17 '22 at 14:39
  • @DanielMann I'm saying your "no, that's not what it is" presumably refers to the subject of my question, which is the "not protected" notification, but the rest of your comment doesn't explain that. – OverLordGoldDragon Jul 17 '22 at 17:18

2 Answers2

7

GitHub Support:

Please do not be alarmed, you have not broken anything on your repository. We introduced a prompt for repository owners and admins to protect their default branches ... the prompt [is] displayed to any admins with more than one branch in a repository.

I've confirmed this, creating branch creates banner, deleting branch deletes banner.

OverLordGoldDragon
  • 1
  • 9
  • 53
  • 101
  • This is all very interesting, but the behavior of some web site, even if it is GitHub, is not a programming matter, so I'd suggest it's off-topic for _this_ site. – matt Jul 21 '22 at 18:50
  • 3
    @matt Might want to revise the `github` tag description then, _"features specific to GitHub"_. Also some of GH's notifs are directly tied to `git` (e.g. merge conflicts), and we had no way of knowing this wasn't the case at the time (i.e. caused by user bad code). – OverLordGoldDragon Jul 21 '22 at 18:58
  • This Is Microsoft's scare tactic to get you to pay for it – TheRealChx101 May 04 '23 at 21:09
  • To the face of Github support/doc team, I was ALARMED... (⩺_⩹) – Naveen Kumar V May 17 '23 at 13:42
0

Git has no notion of protected branches. They are purely a GitHub/GitLab, etc. concept. You should simply click "Protect this branch" to enable branch protection.

I'm not sure why you're repeatedly trying to change the upstream and push to different branches. I'm assuming you're on the same branch running each of these pushes. But if that's the case then you're changing the upstream and which branch your targeting with each push. Git will protect you, but using -f is very destructive since it disables a majority of the existing safety checks including potentially overwriting yours or someone else's work.

Also,

I figured maybe it's a built-in alarm for when someone's forcefully deleting stuff, but I'd like to be sure. Also, I'm sure you're right on -f, but I'll keep doing it - at least as long as it says so in an SO answer

Just because another SO post claims something is the answer, doesn't mean its the same answer in your situation. Trying the same commands over and over won't solve your issue, it'll only serve to frustrate you.

What seems to be the problem?

You're receiving an error that there are multiple refspecs with the name branch_name. My guess is you have names that collide, such as a tag and a branch name that are the same, etc. As a general rule never have tags and branches with the same name. This can cause conflicts with git.

However, let's start simply here. Nowhere do I see any updating of the local refs. Simply updating the refs and then pushing might solve your issue.

Approach 1: Ensuring your refs are up to date

  1. git fetch will keep your git client's refs information in sync with remote.
  2. git checkout branch_name
  3. git push -u origin branch_name

Approach 2: Creating a different branch

Let's create a new branch with a name other than branch_name since there seems to be some sort of conflict:

  1. git fetch
  2. git checkout -b my_new_branch branch_name will create a new branch off of branch_name locally and switch to it.
  3. git push -u origin my_new_branch

Approach 3: Trying to fix the refs issue

If you absolutely must have branch_name as the name, you can try to resolve the conflicts. I'm not sure if the below will work as its untested, based on speculation and I'm unsure how to recreate your scenario.

  1. git fetch will update the git client's refs so they're aware of changes on remote.
  2. git checkout branch_name to checkout your local branch
  3. Delete any tags that conflict:
  • git tag -d branch_name will delete the corresponding local tag.
  • git push --delete origin :refs/tags/branch_name will delete tags on remote that have the conflicting name. You'll get an error if non existent
  1. git push --delete origin branch_name will permanently delete the remote copy of branch_name. Before running this make sure you have all the commits you expect on your local copy. Again, you'll get an error if the branch does not exist.
  2. This should clear up any issues with the refs. You should be able to do git push -u origin branch_name now.
  • Alternatively, you can also try git fetch --prune will remove all branch refs that do not exist on remote.
  1. git tag -a new_tag_name -m "tag message" sha1 recreate the release tag we previously deleted. sha1 is the commit hash of the release you previously tagged.
  2. git push origin new_tag_name pushes the tag to remote and automatically creates a release in GitHub.

I hope one of those solves your issue.

ElderFuthark
  • 496
  • 2
  • 11