1. Bitbucket
  2. Public Issue Tracker
  3. master
  4. Issues


Issue #9288 open

Cannot reuse an old branch prefix as a branch name (BB-11256)

Mark van den Berg
created an issue

Some time ago I pushed a branch called 'dev/some_feature' to a Bitbucket repository. Now I've decided that I want to group my feature branches not with a 'dev/' prefix but with 'feature/', and I want to use a branch called 'dev' as the integration branch with all finished changes.

So I merged and deleted all 'dev/*' branches on Bitbucket and locally. I then created a local 'dev' branch (branching off of the 'master' branch). Now if I try to push this branch to Bitbucket (remote 'origin'), I get the following error:

 ! [remote rejected] dev -> dev (failed to write)
error: failed to push some refs to 'https://mjpvandenberg@bitbucket.org/xxx/xxx.git'

My guess is that, although all 'dev/*' branches have been deleted, there's still a 'dev' folder in .git/refs/heads. I am not aware of any method by which to actively remove this folder, either thru the web interface or with any git-remote command. I don't know how often git-gc runs on Bitbucket and if it will fix this issue. If I use the web interface to create a new branch off of 'master' directly in the Bitbucket repo, the error message says 'Invalid branch name'.

It would be nice if Bitbucket could see that the 'dev' branch name is in fact available.

Comments (42)

  1. Brian youngblood

    same issue here. not able to recreate a branch that was removed - in this case "release" was removed and not able to add it again without getting the "Invalid branch name." error.

  2. John Garcia

    If you're affected by this issue, go ahead and post the owner, repository, and branch info here on this public issue and I'll clear it out for you. Or you can file a private issue at support.atlassian.com

  3. Adam Haid

    owner: solidfire repo: solidfire-powershell branch: release

    Please delete the "release" branch as it's preventing me from creating release/v1.0.1.0

  4. Manish Das

    André Tzermias You are welcome! I wish, there was a way we could do that, it's lame filing ticket for this every time it happens. We have another repo where we have similar issue and now we will have to file a ticket for that as well. :/

  5. Chengjie Liu

    We ran into this as well. This is workaround we used to workaround problem. No need for us to file support ticket.

    • Switch to git ssh clone. Set up ssh key too. git clone git@bitbucket.org:company/gitrepo.git
    • Recreate new branch with same name from ssh cloned repo, ghostbranch in this example. git push origin master:ghostbranch
    • Delete branch again from ssh cloned repo. git push origin :ghostbranch
    • Now you can create a new branch that uses name as prefix git push origin master:ghostbranch/test

    In the end https server is a wrapper of real git developed by bitbucket. It might have a bug not cleaning up file in .git/logs/refs/heads/ghostbranch. Ssh git does this correctly.

  6. Kaleb Elwert

    This is copied from another bug:

    When you select 'close branch after the pull request is merged' and the merge the pull request the reflog is not being cleaned up. This means that any future branches with that name as path prefix cannot be successfully pushed to due to a git error.

    Steps to reproduce:

    1. Create a branch from master called "foo"
    2. Create a commit on foo and push it to Bitbucket
    3. Create a PR from foo to master, selecting close branch after merge
    4. Merge the PR
    5. Create a branch locally called "foo/my-new-branch-name"
    6. Attempt to push a commit to "foo/my-new-branch-name" on bitbucket

    You will see an error from git that looks something like error: unable to create directory for ./logs/refs/heads/foo/my-new-branch-name

  7. Sean Farley staff

    This has finally been fixed in git with the newest version (2.13):

    • Deletion of a branch "foo/bar" could remove .git/refs/heads/foo once there no longer is any other branch whose name begins with "foo/", but we didn't do so so far. Now we do.

    I'll work with Erik van Zijst to try and update our version on Bitbucket.

  8. Log in to comment