Delete the ref based on the 'close' checkbox when a user merges locally

Issue #13524 closed
Dominik Bartholdi
created an issue

This is a follow up bug report from the outcome of the discussion in issue #13311

here is our workflow...

  1. git clone git@bitbucket.org:yooture/dummy.git (done by dev on local env)
  2. cd dummy (done by dev on local env)
  3. git checkout -b feature/FF (done by dev on local env)
  4. echo "Dany" >> contributors.txt (done by dev on local env)
  5. git commit -am "dany" (done by dev on local env)
  6. git push origin feature/FF (done by dev on local env)
  7. create PR for "feature/FF" via Bitbucket WebUI (check "Close feature/FF after the pull request is merged") (done by dev in browser)
  8. git checkout master (done by dev on local env)
  9. git merge feature/FF (done by dev on local env)
  10. git push origin master (done by dev on local env)
  11. git fetch origin --prune (done by dev on local env)
  12. git branch -r (done by dev on local env)

--> origin/feature/FF still exists

also if I do a fresh clone and list all the existing branches, feature/FF is still available...

all this is done on the origin organisation in Bitbucket (no fork is involved)

So from what was discussed with @kelwert in #13311, I would expect the repo "feature/FF" to be deleted after I pushed my merge commit - this seems clearly a bug on Bitbucket site then.

Comments (15)

  1. Dominik Bartholdi reporter

    @sheanfarley - thats not the issue, sure jenkins can delete branches. But in this case Jenkins does not wanna delete a branch, it wants to detect all branches he has to build and a PR branch that has been merged, is of no use to be kept (thats why I marked it with "Close feature/FF after the pull request is merged"). The workflow goes like this:

    • jenkins lists all branches of a given repository
    • for each found branch of the given repo, it will create job (given there is a Jenkinsfile within it) and trigger a build
    • the job will be triggered everytime a change on the branch happens.
    • if the coresponding branch of a create job does not exist anymore, then the job is deleted too

    this feature is implemented in this plugin: https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Multibranch+Plugin and the specific support for bitbucket is here: https://wiki.jenkins-ci.org/display/JENKINS/Bitbucket+Branch+Source+Plugin

    we would be very thankful if you could consider a fix for this soon.

  2. Dominik Bartholdi reporter
    • edited description

    added info about who does the step and where directly to the single steps description, So in the described workflow jenkins is not involved at all - but it Jenkins is listening on all changes of the same repository on bitbucket. The described workflow explains why Jenkins (any everyone else) still sees branches it is not meant to see anymore.

  3. Sean Farley

    I actually think we should implement this but it's a bit contentious here, so I'll have to fight for it. The pushback from some others on the team is, "why don't you delete (then push) the ref if you're done with it?"

  4. Dominik Bartholdi reporter

    I think without this, the flag does not really make any sense and there is no help explaining what "close" actually means either.

    Also: I can't prove, but I was told by others that the flag in Bitbucket Server is actually called "Delete feature/FF after the pull request is merged" - which I think is in fact what a user would expect to happen.

    I think just hiding a branch in the UI is useless and irritating...

  5. Sean Farley

    The name 'close' from Mercurial (you need a commit to close a named branch). Bitbucket Server doesn't support Mercurial so they probably use the 'delete' verbiage.

    There has been some push back on this issue. The issue is that some users don't want Bitbucket to attempt the merge at all, hence we won't try to delete the branch. As I mentioned before, why not just add a step:

    9.5 git push --delete feature/FF

    ?

  6. Dominik Bartholdi reporter

    There are two different use cases/people:

    • devs doing the merge on there local env: here it would be an additional step and you know how easy it is to forget about additional steps. Many of our devs use your other product "SourceTree" and there is nothing that helps them to do this in one step.
    • devs doing the merge via Bitbucket WebUI: these guys would even have to startup an additional tool on there local env to remove the branch, because the branch is not even seen in the WebUI anymore :(

    My feeling is this:

    You should make the "close" option more explizit and really tell your GIT users what it is good for. And maybe you really need a second option for GIT only: "Delete branch after merge" (e.g. a radio button with the options: delete or hide branch after merge). I really talked with many people in the Jenkins community and none of them has understood the flag in the way it actually works today - every single one has interpreted the flag to delete the branch after merge. But yes, I only talked to GIT users and not Mercurial users - but maybe thats also the issue here, you may have to tread them different. And at the end the question still remains, what is the purpose of the flag when the branch only gets hidden from the WebUI, but not from the tools we use to automate all the things?

  7. Sean Farley

    devs doing the merge on there local env: here it would be an additional step and you know how easy it is to forget about additional steps. Many of our devs use your other product "SourceTree" and there is nothing that helps them to do this in one step.

    If this is a problem, why are they merging locally at all?

    devs doing the merge via Bitbucket WebUI: these guys would even have to startup an additional tool on there local env to remove the branch, because the branch is not even seen in the WebUI anymore

    There is some misunderstanding here. If you merge from the Bitbucket UI, then the ref is deleted (and git fetch --prune will delete origin/feature/FF). There is no "hiding". It's either there or it's not.

    I think the rest of your response is based on a misunderstanding. The ref is deleted if you merge through the web ui.

  8. Connor Poole

    I'd love to see a feature where you can specify X number of days after merging please delete the branch.

    We like to keep our branches around for a sprint or two in case something needs to be hotfixed, but after that it would be nice if they automatically deleted themselves

  9. Alastair Wilkes staff
    • edited description
    • changed status to closed

    Given the low interest in this feature since it was raised, and since it is an edge case, I am closing this issue to reflect that we won't be able to address this in the near future.

  10. Log in to comment