Revert/Modify "Create Pull Request" message on remote push commands (BB-13435)

Issue #11409 resolved
Eli Weinstock-Herman
created an issue

We have a well defined continuous delivery pipeline that, as part of it's process, merges changes from master to a reviewed branch and pushes that back to bitbucket.

Recently a "feature" was released that returns a remote message about pull requests when we do a remote push, even with the -q option in git. This is problematic for us because that message is shown in stderr and our build process assumes that any unexpected errors (ie, stuff in stderr when we use the -q option for git push) is an error, so it fails the build step.

Here is what we run and the message we receive:

git push -q origin reviewed

remote: Create pull request for reviewed:
remote: https://bitbucket.org/precisionlender/pl-application/pull-request/new?source=reviewed&t=1

We have also noticed this text is not returned consistently. So that particular build step fails several times in a row and then starts working again, then fails occasionally and starts working again.

Please turn off this unnecessary remote message or make it an option that people can opt-in on. Given that it always reports the same URL, I'm not sure it's providing any value.

Official response

  • Thomas Kells staff

    Hey everyone, Bitbucket dev here. First let me start out by saying we hear your complaint loud and clear. This is something that we have discussed internally for a while now, but it's not as simple as swapping around a few lines of code.

    Ideally git push -q would work, but this is a git client feature that is not forwarded to the server. If you set the environment variable GIT_TRACE, git runs in a verbose mode that will print the command that it's actually sending to the remote.

    EX - λ: GIT_TRACE=1 git push -q origin master 15:02:32.882644 git.c:350 trace: built-in: git 'push' '-q' 'origin' 'master' 15:02:32.900621 run-command.c:336 trace: run_command: 'ssh' 'git-localhost@localhost' 'git-receive-pack '\''test-repo/test-repo.git'\'''

    So the client sets the -q switch which suppresses stdout and sends the command to run to the remote. The remote executes the hooks and rewrites all of the stdout to stderr. This is considered the correct behavior by the core git team as in their opinion hook messages shouldn't be suppressible. The returned value being in stderr means that -q has no effect on the display of the hook text.

    Approximately 15% of all PR creations happen via the link returned from the post-receive hook in the console, so we consider the feature useful enough to keep in the product. We would, however, like it if users who are actively bothered (annoyed or worse) were able to disable this. Currently we are exploring allowing it to be switched off at the user level to have parity with Bitbucket Server. Some users (in this relatively small sample of users) have asked for it to be turned off per repository, which is not currently in the cards.

    tl;dr - We are working on a solution that satisfies the requests of as many people as possible; currently this is looking like a per-user preference that disables non-critical hook messages across all repositories.

    Update - 09/27/2016: todays deployment included an opt-out flag to disable console messages globally per user. This setting can be found in Bitbucket Settings -> Account Settings:

    account_settings.png

Comments (84)

  1. John Hunt

    This is an infuriating feature of bitbucket. I often push things and don't wish to be reminded that I can create a pull request - I know I can.. every time I push I don't need to see this.

    A while back there was a st patrick's day message when pushing too (or something similar). Yes, it's cool that you can add remote messages but it's not professional - it should only be used for very important things.

    Bitbucket, please at least make this an opt-out thing.

  2. Eli Weinstock-Herman reporter

    From my perspective as manager of a team that uses a continuous delivery model and deploys multiple times/day: this has already cost us and due to how slow BitBucket has been to responding and resolving this issue, we will likely have to build a workaround, costing us some development time that could be better spent making valuable things for our customers. BitBucket is not the only option on the market and, at this point, the only value we get over one of your competitors is the built-in integration with other Atlassian products. Raise the level of friction high enough, and it will eventually be cheaper for us to integrate a competitors product and pay them that portion of our monthly fee instead.

  3. PhilipDanielsLandmark

    Glad to note I am not the only one annoyed by this. And the wording is confusing, I thought it was saying that BitBucket HAD created a pull request so I went looking for it on the website. Apparently they couldn't afford the bandwidth to transmit "To create... navigate to:".

  4. Greg Wiley

    Support asked me to add my $0.02 here.

    Chatty server response is not wanted. Mixes noise into the operational information. If we train ourselves to ignore it then we may miss actual signal from the service.

  5. Jake Menashe

    +1 for opt in/out. Seems like this should default to off. I also think that these kinds of global changes should be avoided in the future unless an opt out is available.

  6. Pablo Funes

    This is a small big problem and it should be taken care of ASAP.

    I stumbled upon these weird messages while testing Bitbucket in sight of a possible migration.

    As a Git user switching to a new host, this erodes your confidence: they seem to be doing funny things when I commit.

    The only feature you need from someone who hosts your repos: reliability and trust. Can I trust Atlassian to not mess up with my repositories?

  7. Igor Baidiuk

    Should be turned off by default. I'm using console heavily, and all that chatty stuff annoys me greatly. Atlassian, what have you done to once good and promising service?

  8. Eli Weinstock-Herman reporter

    We have now spent developer time putting in logic to filter out this particular message during our automated process. So this has now directly cost us (your customer) money.

    I'm also now using this as an example to our development team on how not to release features and to underscore why it's important to resolve these types of issues quickly instead of letting them linger for weeks.

  9. Igor Baidiuk

    I'm rather pessimistic on this. Large companies tend to ignore any complaints, except when they risk losing a lot of money. The positive way would be to have separate list for planned features, with users able to upvote each one. Alas, we're just presented with results and can either get used or go away.

  10. Danish Goel

    Can be a good feature, but is also very confusing.
    I encountered this today and was worried, that maybe the push didn't happen correctly.

    Would be nice to have this feature as an option, maybe at the project/team level?

  11. Daniel Arnold

    I use different branches for all my projects and it's very irritating to see this message every single time I push to a branch that isn't master. Anybody that uses a popular git branching workflow, including git-flow, will have this same exact issue. It's irresponsible to introduce a feature like this without providing an opt-in or opt-out at all. Additionally, the message is padded with newlines above and below it, which takes up even more console real estate.

  12. Curtis Farnham

    I would like to add my voice to the growing crowd of Bitbucket users who say adamantly: "Get rid of this message!" Or make it turned off by default. There is no reason to impose this message on everyone all the time. I am a one-man dev team, and have no need for pull requests.

  13. Denis Davydov

    should be turned off by default. Please, do so ASAP. It is very annoying, and the text (as mentioned several times above) is confusing. No PR is created (luckily). I am also heavily using branches and merge them locally, when needed.

  14. Eli Weinstock-Herman reporter

    Some interesting quotes:

    • Atlassian Core Value, "Don't #@!% the Customer": link
    • "Empathy is at the core of Atlassian and readily apparent in our company values. One such value is “Don’t #@!% the Customer” which reminds us all to care first and foremost for our customer needs." link
    • Our product team is defined by its connection to customers. Their favorite word? Empathy. If we could not empathize with customer pain points, we would not be able to create solutions to solve their problems. link
    • Mike Cannon-Brookes: "It’s always customer empathy, right?” he asked the audience. “Design is really about empathy, not beauty. It’s not how it looks, it’s how it works and fits together. At the end of the day, if a customer has a good experience using your product, that’s the end criteria." link
    • OnDemand Webinar named "Designing for Empathy in the Enterprise": link

    We are usually happy users of your product, but this feature has cost us, caused pain to a number of people that have posted above, and annoys me all over again as each new posting has been added over the past 2 months. From what I can tell, it runs completely counter to your core values and if it were my engineering team I would have upgraded this to a critical ticket not only to show the marketplace how important our core values are, but to ensure that it is clearly visible to all of the employees that come in contact with it too. For each ticket like this, you end up spending some number of dollars internally and externally to shore up the belief in your values, explaining that, yes, causing the customer pain really is something that every employee is empowered to prevent and that we should look at tickets like this as the exception that fell through the cracks and not the reality behind the values.

  15. Igor Baidiuk

    @Eli Weinstock-Herman They have top-voted issue with 2000+ votes, hanging here since 2012. Atlassian gave it some attention only about 1-2 months ago. And what they told is : "Oh guys! We're such a busy here! We have hard time integrating pastebin gists. Doesn't matter it's not even top-5. Oh, this one is top-voted? Umm, ok, we'll look at it in maybe next 10 years. We're just not sure". So be patient :) it seems Atlassian guys look only at 1st issues page, and only after it's been around for at least a year.

  16. Bogdan Zurac

    This needs to get even more traction. Unbelievable how they could just publish a new feature like this, but at the same time not providing an opt-out feature...

  17. Daniel Rozeboom

    Another vote to disable this by default and/or add an option to disable. I thought the pull request was required as well when I first saw the message. Unnecessary for single-developer projects like mine.

  18. Simon Orr

    Just a pity that for the other 90% of users who actually know how to use the tools, it's an annoyance that messes with automated builds and causes confusion.

  19. jaredtritz NA

    Well, I'd really like to simply see that my push succeeded in 3-4 lines rather than have to read through an error length message of 12+ lines to find the words "Create pull request", which means I can ignore the message. For what it's worth I'm pretty sure that's what everyone here is saying.

  20. Euan Reid

    Another +1 here. Useful feature for Stash when I want to tell a team to use pull requests because that's our process. Not so useful here. Terrible customer service to force it with no opt-out except "use stash/another provider".

  21. Igor Baidiuk

    @Nam Nguyen It seems so. I tried to draw their attention to overall situation in their blog. But alas, I received only answer from someone supposedly from Bitbucket addon team, and she had no idea what's happening in core team. So basically yes, it seems they intend to keep this issue open for quite some time, like many others.

  22. Paul Backhouse

    Why not write your script to work off the exit code returned by git. Eg:

    $ git push origin somebranch
    Everything up-to-date
    
    $ echo $?
    0
    
    $ git push banana somebranch
    fatal: 'banana' does not appear to be a git repository
    fatal: Could not read from remote repository.
    
    Please make sure you have the correct access rights
    and the repository exists.
    
    $ echo $?
    128
    
  23. Simon Orr

    re: "Why not write your script..."

    Some of us aren't calling this from scripts, but from automated processes which aren't always easy to modify.

    Doing it to handle this unique case where stderr should be ignored only introduces complexity.

    stderr: The clue's in the name.

  24. Anonymous

    This is ridiculously annoying. Just because you like using pull requests doesn't mean that you should push your methodology onto others. Please stop doing this.

  25. Willem Mali

    The way Atlassian deals with bugs (this being one of them) has convinced me to make the jump from Bitbucket to self-hosted Gitlab; so far it's pretty great!

  26. Thomas Kells staff

    Hey everyone, Bitbucket dev here. First let me start out by saying we hear your complaint loud and clear. This is something that we have discussed internally for a while now, but it's not as simple as swapping around a few lines of code.

    Ideally git push -q would work, but this is a git client feature that is not forwarded to the server. If you set the environment variable GIT_TRACE, git runs in a verbose mode that will print the command that it's actually sending to the remote.

    EX - λ: GIT_TRACE=1 git push -q origin master 15:02:32.882644 git.c:350 trace: built-in: git 'push' '-q' 'origin' 'master' 15:02:32.900621 run-command.c:336 trace: run_command: 'ssh' 'git-localhost@localhost' 'git-receive-pack '\''test-repo/test-repo.git'\'''

    So the client sets the -q switch which suppresses stdout and sends the command to run to the remote. The remote executes the hooks and rewrites all of the stdout to stderr. This is considered the correct behavior by the core git team as in their opinion hook messages shouldn't be suppressible. The returned value being in stderr means that -q has no effect on the display of the hook text.

    Approximately 15% of all PR creations happen via the link returned from the post-receive hook in the console, so we consider the feature useful enough to keep in the product. We would, however, like it if users who are actively bothered (annoyed or worse) were able to disable this. Currently we are exploring allowing it to be switched off at the user level to have parity with Bitbucket Server. Some users (in this relatively small sample of users) have asked for it to be turned off per repository, which is not currently in the cards.

    tl;dr - We are working on a solution that satisfies the requests of as many people as possible; currently this is looking like a per-user preference that disables non-critical hook messages across all repositories.

    Update - 09/27/2016: todays deployment included an opt-out flag to disable console messages globally per user. This setting can be found in Bitbucket Settings -> Account Settings:

    account_settings.png

  27. RobB

    Assuming that output on stderr is actually an error, is really quite ignorant, at best.

    @HL Staff please do not remove this feature. It is quite useful and should not bother anyone who knows what they are doing.

  28. Mike Chabot

    How do enterprise users disable this message? I do not have a "Bitbucket Settings" under my user icon. I logged in as our admin, and still see no such setting at the user level. Please advise.

  29. Log in to comment