POST service does not provide useful information when merging to a branch (BB-8954)

Issue #7775 resolved
Christopher Dow
created an issue


When I merge to a branch, the POST service sends me the following data: payload:

 "repository": {
  "website": "",
  "fork": false,
  "name": "august-rest-api",
  "scm": "git",
  "owner": "chrisbk",
  "absolute_url": "/chrisbk/august-rest-api/",
  "slug": "august-rest-api",
  "is_private": true
 "truncated": false,
 "commits": [],
 "canon_url": "",
 "user": "cdow"

The problem is that there is no information about the branch there. I can work around this to suit my needs, but it is a bit silly that there is basically no useful information in the POST. Also, I'm setting this as a bug because the actual behavior is pretty far from the expected behavior and the docs do not explain this.

Comments (191)

  1. Erik van Zijst staff

    This particular POST was most likely the result of a git push that didn't actaully push any new commits.

    This happens for instance when you create a tag. Or a new branch that points to an existing commit.

    For better or for worse, Bitbucket's POST service currently only reports commits that are pushed up and did not already exist on our side.

    If you think that this was not the case here, feel free to provide me with the exact timestamp of the push, so we can correlate it with the repo's reflog (you can do this locally too).

  2. Christopher Dow reporter

    Thanks for accepting it, Eric. The reason this is a pain for me is that I want to use merges to branches to trigger deployments to test, staging, & production. I have a work around, but it's squirrely and ads what I believe is an unnecessary step.

  3. Chad Kimes


    This is huge for our continuous integration. We build every time our staging branch gets updated, but we only ever merge into staging - never a direct commit.

  4. Justen Stepka

    Official update:

    We've had re-designing our commit hooks on the short list of features we'd like to improve soon as there is extra time. At this time though, we do not have an estimate for when this feature will be implemented. Our focus for the short to medium term, will be to provide SSO and better user management with our OnDemand JIRA and Confluence products. I would estimate that the SSO integration and bi-directional oAuth integration between Bitbucket / JIRA / Confluence / Bamboo will take us into 2014, at which time we will re-evaluate this decision.

    Cheers, Justen -- Bitbucket product manager

  5. Lubomír Štork

    Justen Stepka: this is really bad news. If payload at least contained info about related branch, it would be enough for me (I'm not really interested in full list of commits, only info I need to know for my deployment solution is name of updated branch).

  6. Jannis Gundermann

    @Justen Stepka I have to agree with @Lubomír Štork here.

    This type of basic information being transmitted in the POST hook is what's needed by many automated deployment solutions.

    Currently this broken feature literally means I cannot use my deployment solution in which I'd deploy when a push is happening into the master branch. Following the GIT Flow principal, what ends up in master is usually already in the dev branch hence triggering this issue discussed here and breaking the deployment process.

    I'm not entirely certain how something as vital to the deployment process can simply be pushed aside with a "maybe in 2014 sometime" comment.

  7. tobie.warburton

    bitbucket team - it'd be great if you could fix this soon. it's something which is beginning to get on my teams nerves, and i'm sure others agree.

    it almost defeats the point of continuous integration.


  8. rujmah

    Ah, good to see this has already been raised.

    Have voted this up and would like to see this implemented soon. Would like to stay with BitBucket, but this might be the reason we have to leave (or set our own repo mgmt up, which would be a pain...)

    Please implement!

    Thanks, R

  9. Anonymous

    2013-07-16... if it takes months to fix this "string output", then the reason for fixing a "critical" bug is not technical. management or brand protection perhaps.

    Work-around for me was to use a second check to see if branch X had been updated (in bash). What other solutions are recommended/used?

  10. Bradley Batt

    Agree with this issue as it makes auto-deploying a pain. For those looking for a fairly easy workaround, turn off fast forwarding when merging. You can do that on the command line…

    git merge --no-ff develop

    Or specify in your .git/config file…

    [branch "master"]
            mergeoptions = --no-ff

    This creates a new commit for the merge, which will force the correct information to be sent via the webhook.

  11. Genadijus Paleckis

    @Brett Brett with this configuration when pushing to remote branch commits information also will be sent to remote branch, and post hook that was fired from bitbucket will contain information about branch and each and every commit that was merged into that branch. For instance mine deploy script looks like this:

    $payload = json_decode($_POST['payload']);
    $update = false;
    foreach ($payload->commits as $commit) {
        if ($commit->branch == 'development') { $update = true; }
    if ($update) { system("../bin/update"); }
  12. Jerome Guilbot

    We use this for CI based on multiple branches (master + multiple feature branches per project). As noted before, the payload doesn't contain branch information in the case of a fast-forward so our system doesn't know which branch to pull from. The only workaround I can think of so far is to pull changes on all branches no matter what when an empty payload is detected => awful overhead and extra logic :/

    Does anyone have any other suggestion?

    cc @Yohan Lebret

  13. Nathan Palmer

    FYI, We just switched our repositories off of BitBucket and this was one of the reasons. Having a reliable continuous integration process is key to our ability to execute quickly and consistency. This bug affects our CI servers ability to build from the right branch which in turn gets in the way of getting work done. /cc @Justen Stepka

  14. Cody Hatch

    Since this breaks CI/CD integration with Bitbucket, this seems like a critical blocker that stops us from being able to use Bitbucket. Kinda shocking this has gone unfixed so long.

  15. Keith Pitt

    Hi, I'm a developer of a CI service called Buildbox (

    I've had complaints from my customers that this doesn't work. This is pretty poor. You guys really have dropped the ball on this one.

    Please fix. I have voted. I doubt anyone will read this anyway.

  16. digiworks

    And then, almost one year after, there is absolutely no news. I guess I have no other choice but leave Bitbucket and find another service for my Git repositories. There is nothing professionnal in letting his customers waiting so much time without doing anything...

  17. Jeremy Ebler

    I ran into this nearly a year ago when making a custom HipChat notification service, and now again while trying to integrate with a CI/deploy service.

    This is ridiculous. I push code to development, CI runs, all green. Then I push the same code to master, and nothing happens.

  18. Graham Budd

    It would be great to get this fixed. The workarounds are all not ideal. Right now I have the team creating a commit and ignoring fast forward, but of course it is still a source of problems when someone forgets this. Like many others here, all I need is the branch information included in the merge payload. Any idea when this will be addressed?

  19. Jimmy Henderickx

    We are paying for 100 users for our organisation.

    Not having this is for us not an option, we need decent triggers. Please implement this or we will be forced to move to another partner.

  20. Richard Tape

    Of all of the issues marked critical, this (comfortably) has the most votes. It's also one of the oldest and as such would have more votes but there are lots of +1s which were added before the voting system came in place. It's also one which has lost you customers and is preventing you from getting some more. It's marked critical by an employee, but to many it's a blocker. I'm not entirely sure how after all this time, there's no update on this let alone a resolution. Come on BitBucket, this functionality is vital to a modern-day deployment system. You're hurting your users and hence you're hurting yourself.

  21. Brad Murray

    Just ran into this today. The last thing I wanted to see is that it is a year old bug with no comment from the vendor in 5 months.

    Can we simply get a status update? ETA? Limerick? Haiku? Anything?

  22. Yuriy Padlyak

    May be it is rather political, not technical issue :) Resolving it will allow integration with other services. On the the hand, without it fixed, users are tied to their sevices.

  23. Michal Zdrojewski

    @gneeot You are most likely right about this issue. Atlassian was more interested in bringing new dashboard than fixing a real problem, so the decision seems to be business driven. The fact that this is/may be their business approach tells a lot about the company and should provide food for thought to anyone considering what provider to use. It's a shame that most of those people will only realize after they committed.

  24. Brad Murray

    I don't know if I would go into conspiracy theories. The deepest I would go is stating that sometimes those doing the work and deciding what work gets done are not the same people.

    I will confirm @Bradley Batt 's no fast forwarding change is a 2 second change in SourceTree and fixes the issue immediately. Tools -> Options -> Git -> Check “Do not fast-forward when merging, always create commit”. Presto, Continuous Deployment working. See if you are looking for a good sync tool also, few simple PHP files and you are in business.

  25. A

    It seems that rebases are also handled incorrectly: the commits which are on the base (upstream) branch are not included in the payload; only rebased commits are.

  26. Jaime Barrajón

    The --no-ff option might be a workarround, but it doesn't fix the problem. The POST-hook guide has a small sample of the payload data sent, but lacks documentation of the data! Check Issue #9762 for instance, there's a branches array (empty?) in some commit objects, but not always. This also happens on other parameters, depending on the pushed event. So yeah, poor documentation and poor support from Bitbucket is driving people away from their services. Great job, team!

  27. Tom Foyster

    The lack of response on this issue has entered the realm of ludicrous. Yes, the SourceTree fix works, but surely the right solution here is to fix the problem at the source? No pun intended...

  28. Harry Curotta

    I've had lots of problems getting Codeship to detect merges on our staging/dev branches for a deploy. I came up with a fix and have used it for a few weeks now and it seems to work really well. This should work well for other CIs too.

    I wrote a gist for it. Basically it involves implementing a post-merge git hook to force an empty commit to occur after each merge action to your specified branches. It pollutes the commit history a little, but the payoff is worth it.

  29. D

    Yeah, just ran into this with CodeShip. We were going to use BitBucket instead of GitHub. Perhaps that was the wrong choice. Hrmmm. Really woulda hoped this wouldn't be an open issue a year later :P

    At the very least, make it a flag to enable/disable this per repository. That way folks can enable, but you don't have to worry about rolling out to everyone / breaking previous functionality.

  30. Robbo

    What this issue represents (lack of even small changes to bitbucket when clearly needed which shows lack of any work at all on bitbucket) plus down time with ssh issues and a pretty terrible API overall (even the RSS feed is useless) is why we are forced to look into other solutions.

  31. Tom Foyster

    This is not good to see at all. Currently leading a large organisation into using Version Control and this level of support, or lack thereof, is a major warning flag when it comes to deciding whether or not to choose Bitbucket to manage our Repositories.

    I have managed to us the -no-ff workaround, but lets face it, its a far from ideal solution.

  32. Ivo Kund

    @Erik van Zijst Are there any updates on this issue? We are in a process of migrating from Github to Bitbucket with my company (10+ developers) and I just stumbled on this issue.

    This is a definite show-stopper, as Codeship/CI deployments are essential parts of our workflow. Honestly, the way this has been handled so far by Atlassian seems very frightening and if there's no reasonable update on the issue, then we need to stick with Github (like many many other people in this thread).

  33. Roland Christen

    Soon some new projects will come up, where I intent to use CD. Right now, I can't do this on bit bucket without a lot of efforts for workarounds. Can you give us an estimation when and if you intent to solve this issue? If you are not going to solve this, please just let me know. I can live with that, I just need some planning reliability for my upcoming projects. Thank you for a short answer like "won't fix this", "will fix this within {timespan}..", "won't fix this before {date}"

    thank you very much. And besides that major issue here, good service! Keep it up!

  34. Tim Moore

    I'm not sure if this is related, but I just noticed some strange notifications in systems integrated with Bitbucket when a colleague and I both merged separate topic branches to the same upstream branch at nearly the same time:

    One of the HipChat notifications did not detect the branch correctly:

    10:07 am
    Multiple authors committed to 0 branches at /cultureamp/murmur/
    10:07 am
    Multiple authors committed to 1 branch at /cultureamp/murmur/
    On branch "develop"
    ... (commit details)

    The CI build for the same merge also did not detect the branch (we use wercker):

    A new build started on unknown

    Note that in this case, we merged the pull requests using the Bitbucket web UI and there are merge commits.

  35. Harry Curotta

    Congrats guys, I've just migrated my team over to Github after struggling by with the fix I outlined above.

    I moved purely because of this. Pull Requests and CI are a key part of our workflow.

  36. Tom Foyster

    The fact this bug is almost 18 months old and is without a solution, or even some closure on why you won't support it, it utterly laughable.

    I can only presume its because you want to push people to use your own services, which if so is fine, you're a business, we get it. But at least come out and say so so we can all get on with using something else.

    Going to grace us with a response, @Erik van Zijst ?

  37. Roland Christen

    I fully agree with Tom Foyster. If you are not going to solve this issue, I am ok with that. It is really up to you. But please be fair and let us know if you do not indent to solve this. I would consider it as very disrespectful and unfair to keep us in the dark. Planning reliability is important for upcoming projects. thank you.

  38. Lubomír Štork

    It really takes too long. When I reported this issue in #7854, it was marked as duplicate of this ticket almost instantly and I am sick of using workarounds for that basic thing. Let us know before end of this year WHEN (or IF) you'll do something with it, please. Or, keep silent and I will convince all clients to switch over, your unsaid FSCK YOU, our customers is just too loud.

  39. Maik Ploigt

    The lack of support is getting ridiculous. I just removed all my repositories from bitbucket and will advice all my clients to switch to another service too.

  40. Robbo

    We already have "switch to gitlab" on our roadmap because of what this issue represents (not caring, stale service, issues issues issues)

  41. Ike DeLorenzo

    We are beginning an effort to expand and improve the ways in which developers and customers integrate with Bitbucket.

    As part of this, our webhooks will be improved over the coming quarters, and new hooks will be introduced (a new webhook will probably be needed to solve this issue).

    Requests on this issues board and in other customer forums will help guide our priorities. In addition we would like to invite integrators, customers, and developers of third-party software for Bitbucket to participate in a series of conversations with the Bitbucket product managers so we can best understand what you'd like to see in the next version of our APIs and other integration points.

    If you'd like to participate, send a note to and we will get back to you with next steps.

    • Ike DeLorenzo, PM, Bitbucket
  42. Marko Locher

    Ahoy @gneeot, could you write us another in app message? Codeship should build branches other than master just fine, unless the push is a merge (of commits which have been previously pushed to the remote repository) Might have been a misunderstanding regarding the answer!

    Disclaimer: I'm working for Codeship.

  43. Ethan Setnik

    I just got bit by this bug as well when using Codeship w/ Bitbucket integration. I think the response from Atlassian to this clearly important issue is just plain sad. I'm currently shopping for Github plans as a workaround.

  44. Dan K

    This is a huge problem! I just ran into this while setting up a Jenkins server and I was pulling my hair out trying to fix the problem, only to find that it wasn't Jenkins! I can't believe that there hasn't been an official fix for this in over a year; it's shocking.

  45. Luis Delgado de Mendoza

    1 year and 9 months later and no solution for this problem...

    Does anybody know a good replacement for Bitbucket? My only requirements are: accepts Google as an identity provider and allows configuring access control for the repos.

    Anybody has ideas?

  46. Graham Budd

    Is this now working for anyone else? I've seen some POST HOOK data come in over the past day or so that looks like maybe merges finally have useful branch info?

  47. Giles Williams

    Switching to github next week. Shame as we know some of the founders at Atlassian. Might have to get them to take a look at some of the clearly useless product management within the bitbucket team.

  48. Daniel Holmes

    I'm contacting journalists to see if we can't get some more mainstream visibility on this issue. For paying customers this is a complete frustration and eventually when they realise how long things are taking to even get a response: a reason to move on entirely from bitbucket.

    I thought I'd note that this even effects things like publishing packages to packagist which composer rely's on. If you use the git-flow technique of managing development, this pretty much screws over your ability to make any releases whatsoever.

  49. Daniel Holmes

    @Erik van Zijst can we please get an update on where this is internally?

    With 308 votes and conversations spanning the two years this has been open, Atlassian should be able to see that this is a) A critical issue that could potentially effect Atlassian's bottom line, and: b) pushing away some of your most passionate customers, who's word of mouth is critical to the brand image of your company.

  50. Daniel Holmes

    The fact that BitBucket customers haven't left in droves is a testament to how passionate users are about BitBucket and really emphasises the need for this issue to be resolved in a timely manner.

  51. Peter Horvath

    If you think about the thousands of users that 308 vote is not that big. Just because there are some loud people who are in pain because of this issue doesn't mean that a big company will make this issue a priority. We suffer because of this issue as well but we us ThoughtWorks Go as CI and it is not a life threatening issue for our implementation.

  52. Lubomír Štork

    The main problem as I see it has several angles of view:

    • time (is money), 2 years of approved bug with blocker priority is just too long
    • history (look it up, there are official reactions from the bitbucket people here - yet, they do not keep their word in sync with reality)
    • most important one, this thread is completely ignored from the bitbucket team

    Keep in mind that we're talking about thing, which works just fine for every other service, @Peter Horvath

  53. Ethan Setnik

    I'm considering the possibility that this is not a bug and is actually implemented as designed? Atlassian also owns their own CI tool Bamboo which is "miraculously" unaffected by this issue. It could be a malicious attempt to thwart clean integrations with third party CI tools. Let's be honest, if they wanted to fix this issue, they would have already. It can't possibly be more than one day of work to fix.

  54. Robbo

    @Ethan Setnik more likely they want you to use stash instead.

    We will be moving to github or gitlab once time permits because of what this issue represents and the general bad uptime of bitbucket over the past year combined with the complete stagnation it has. When we moved here bitbucket issues were far better than github issues (main reason for the move, other than githubs terrible ux) but now github has improved to the point where they are just as good.

  55. Chad Kimes

    @Ethan Setnik, it's a bit more damning if you consider that this is something that actually used to work. It broke around 2 years ago now and hasn't been touched. We're not asking for a new feature to be added, we're asking for a formerly working feature to be fixed.

  56. Daniel Tao staff

    Hey everyone, I'm one of the team leads on Bitbucket.

    First, an apology. I've been casually monitoring some issues related to webhooks (more on that in a moment) with the intention of keeping in touch with the community, gauging sentiment, and providing updates here and there, over the past couple of months. I've dropped the ball on that one, and for that I'm sorry. Clearly the silence from Bitbucket on this and other webhooks-related issues has sent the wrong message: that we aren't listening or—worse—that we don't care. Rest assured that isn't the case.

    Now for the good news. Despite my failure to communicate this, my team is actually actively working on making some big improvements to Bitbucket's webhooks. I can't reveal all of the details, but what I can tell you is that:

    1. The work we're doing will certainly address this issue (our improved webhooks will provide plenty of information when merging to a branch and in a host of other scenarios); and
    2. We're making lots of other improvements as well; and
    3. It won't be too much longer before our work is deployed and ready for you to try.

    All that said, I understand some of your frustration, particularly in light of the fact that this issue has been open for a long time. I know posting this doesn't negate that fact; but I did want to let all of you know that we're actually coming up very soon to a resolution to this issue, among other major improvements to our webhooks. It's not just on our roadmap; we're working on it now, making progress and getting closer to an initial release with each passing day.

  57. Graham Budd

    @Daniel Tao Thank you for the update. The description sounds promising, looking forward to when it is implemented. Any specific timeline you can share would be great. We are currently reworking our CI system and would love to build it with the updated POST hook in mind.

  58. Jonne Nauha

    +1 Just bit me on my custom CI server, cannot trigger release builds by detecting branch as the commit list is empty. Well everyone here probably knows the drill.

    Waiting for something new to try again, hopefully this wont take too long.

  59. Chris Kelley

    Like the new Webhooks view / load requests features. After it was implemented I lost all of my previous saved post hooks. After adding them back in... no branch data in logs. Seems to work though.

    04/27/2015 11:25:10 pm Deployed branch: master Commit: 15d26f1

    06/12/2015 06:41:17 pm Deployed branch: Commit: f036b4e

  60. Daniel Tao staff

    Hey everyone:

    As you can see from the announcement on our blog today, we recently launched new and improved webhooks which resolve this issue along with a bunch of other improvements over our previous POST service. (We actually launched these quietly a couple of weeks ago along with Connect for Bitbucket, but I was waiting for the official announcement to update this issue.)

    To be concrete, here's a snippet of an example payload that you would now receive when merging a branch:

      "push": {
        "changes": [
            "old": {
              "type": "branch",
              "name": "master",
              < more properties >
            "new": {
              "type": "branch",
              "name": "master",
              "target": {
                "type": "commit",
                "hash": "49c763e3b987729dfd973e785d58a99ae0febd60",
                < more info about merge commit >
            < more properties >
      "actor": < user info >,
      "repository": < repository info >

    That's just a hand-pruned excerpt—I omitted a bunch of info for brevity—but you can clearly see that with our new webhooks it's simple to identify any and all branches impacted by every push event.

    For more detailed information you can read our documentation (we also have docs describing all of our currently supported event payloads).

    As I mentioned in my previous update, and as the blog also states, this is an initial release, with more features on the way. But since what we have now does address the specific problem described in this issue, I'm going to finally mark it as resolved.

  61. Barry Woolgar

    It's possible that Codeship need to update their integration to match whatever BitBucket have done to 'fix' this. I know Semaphore have a problem still because they don't feel it's a particularly high priority for them given how few of their customer base actually use BitBucket.

  62. Paul Bean

    Issue is most definitely not resolved. standard merges still do not trigger deploys on codeship. we will be one of the many that have already transitioned to other solutions like github. I was planning on having our startup company migrate to other atlassian products like hipchat as well to keep everything under one roof but when almost 2 and a half years have gone and this very essential problem is still not resolved and the ticket was closed out without verification by users...can't throw money at that.

  63. Jonas Peschla

    @Paul Bean, maybe it was resolved as 'Won't fix' because, uhm, maybe it's not important. It really is fun to have automated testing where you have to remove all merged branches by hand. So its semi-automatic testing thanks to Bitbucket. I wonder what the problem is, can't be too hard to fix that if the signaling itself works, just fix the payload.

    Is there a follow up issue we can vote and wait for some more years?

  64. Daniel Tao staff

    For those reporting that this issue isn't resolved: I am going to use my psychic powers and guess that you are all arriving here from Codeship's documentation here, specifically the part where they say this:

    There is a bug with BitBucket web hooks, which won’t supply needed information for pushes which don’t include new commits.

    I certainly don't blame Codeship for directing you here. If I were them I'd probably do the same thing. However, what you may have missed is the part at the top of that section where they say this:

    BitBucket recently released a new implementation for their webhooks, which we are currently evaluating and will switch to in the future!

    The fact is that our new webhooks do include branch information, for all commits including merge commits.

    I have personally chatted with the VP of Engineering at Codeship and will reach out again to see if there's anything we can do to help with their migration over to our new webhooks. Naturally product priorities change all the time, but last I spoke with him their implementation was pretty close to being ready. Obviously, don't take my word as any sort of promise on Codeship's behalf; my point is that the ball's really in their court now. From the Bitbucket side, though, this issue really is resolved: we've released a better, more scalable, more feature-rich webhooks system with a super-useful admin UI and a well-documented API. To learn more, check out our documentation on managing webhooks and our API docs.

  65. Log in to comment