Why is Git branch deleted on remote resurrected another day?

493 Views Asked by At

I have renamed a local branch, deleted the same on remote, pushed the new name to remote and set the tracking like this:

git checkout my_branch
git branch -m my_branch feature/my_branch         # rename
git push origin :my_branch                        # delete on remote
git push --set-upstream origin feature/my_branch  # push and set tracking

I've done this for 20+ branches (via a script) and there were no errors.

Contributors did git fetch --prune and had updated their local branches (renamed and set new tracking branch).

A day after (on Friday), without any new commit being pushed, the old origin/my_branch reappeared on the same commit as the origin/feature/my_branch. There was no new commit & push that someone could have done by using the old tracking branch. So, I have deleted origin/my_branch.

Yet again today (after the weekend) the origin/my_branch reappeared on the same old commit (dated to Thursday) as origin/feature/my_branch is on.

I don't see how and why Git (garbage collector) could resurrect the deleted branch, but possibly the reason is at Gitblit (which handles my remote administration) side?

1

There are 1 best solutions below

5
On BEST ANSWER

It doesn't make any sense unless one of the following is the responsible

  • Some else on your team is pushing this branch again
  • External code (hook, script, cron etc) is creating this branch.
  • It is the default branch defined in Gitblit so its being re-created

The common between those all is that someone (person or script) is creating/pushing this code.


The most likely to happen is that Some else on your team is pushing this branch again.

As for git version <2 when you write git pull/push without specifying remote or branch it will pull/push all your branches. It was updated on version 2.


Git v2.0 Release Notes

When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default is now the "simple" semantics, which pushes:

  • only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or

  • only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from.

You can use the configuration variable "push.default" to change this. If you are an old-timer who wants to keep using the "matching" semantics, you can set the variable to "matching", for example. Read the documentation for other possibilities.