3

Edit: Unrelated to GitHub. Problem was an error in sync script (see comments).


I have been trying to solve this problem for a couple months now & I have come to the conclusion that it is directly related to GitHub.

I am a member of the Stendhal project & we have our source code hosted on GitHub & SourceForge.

I started to have warning or error messages coming up about ambiguous references to "master". After some investigating, I discovered that someone had created a tag named "master" in the Git repo. The GH & SF repos are kept synced automatically. I could no longer push my commits using git push origin master. I had to specify the reference to the master branch: git push origin refs/heads/master

Not only does the tag's presence cause issues with fetch/pull/push, it also causes the tarball downloads from the site to be out of sync with master branch. When a user downloads the "master" tarball they actually receive that of the "master" tag instead of branch.

Now that I've got this much figured out, the issue that I'm dealing with is permanently deleting the tag from GitHub. Any time I delete it, by way of git push origin :refs/tags/master or by simply using GitHub's web interface, it automatically regenerates within seconds. An interesting detail is that when it is recreated, it is created from master branch.

I understand that the tag will be recreated if users have the tag in their local repos & push them to remote. So I understand that I need to get all users to delete this local tag. But the tag is not being recreated from a push. For some reason, beyond my understanding, GitHub automatically regenerates this tag within seconds of its deletion.

I originally thought the issue was occurring on both GH & SF because the tag kept reappearing on both sites. But it wasn't until recently that I discovered that the reason it reappeared on SourceForge was because of the software that is keeping the two repos in sync. Whenever the tag is recreated on GitHub, the software is prompted to mirror the changes on SourceForge.

I have discussed this with members of my own project & on the GitHub IRC channel. But I have not yet found an answer to why this is happening & how to prevent it.

Searching around on the internet, the information I come across deals with how to delete remote tags. But I have not found anything that references a tag named "master" & what I am dealing with on GitHub.

Our project tags are found here on GitHub. Currently, the master tag is at the top of the list & in sync with the master branch. But that will change as soon as new commits are pushed to master branch. The tag list on SourceForge is here. At the time of writing this, I have deleted the master tag so it will not be listed on SF. But I believe that will change when repos are synced again. Not sure if simply pushing commits will cause the tag to be recreated on SF, or if it will only be triggered by changes made directly to the tag itself on GH.

AntumDeluge
  • 133
  • 1
  • 10

1 Answers1

0

During a regular git push, if git pushes a given reference (say refs/heads/master, or refs/heads/some/branch), it will also push any tag which point to any commit in the history of this reference.

Therefore : you may delete the remote tag, and your local copy of the tag, but if anyone else with the rights to push to your repo has the tag locally, he will re-create the tag on the central repo on his next push.


One way to prevent this could be : forbid all users from pushing a tag named master on your central github repo (I am not familiar with Github's authorization rules, I will let you search how to do this), then delete the remote and local tag.

LeGEC
  • 29,595
  • 2
  • 37
  • 78
  • Unfortunately, the problem is not tags being pushed by users. But rather, GitHub itself regenerating the tag as soon as it is deleted. – AntumDeluge Oct 08 '18 at 10:49
  • hmmm ... that's odd. Is one of the repo a `--mirror` of the other one ? or is there some sort of auto-poll of one clone from the other ? – LeGEC Oct 08 '18 at 13:36
  • Yes, it turns out that there is a bug in the script that keeps the repos in sync. – AntumDeluge Oct 08 '18 at 19:35