Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-4225

Disable automatic adding of new commits to existing pull request

    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      Background

      We are currently evaluating whether we could replace Crucible by Stash and its Pull Request feature. So far, Stash's ability to create pull requests in combination with its Branching Model looks very promising.

      However, we stumbled upon the following issue:

      Present Situation

      Currently, new commits to a branch (for instance, feature branch) that is involved in an open pull request (for instance, from that feature branch to the main development branch) are automatically added to that open pull request.

      Feature Request

      It should be configurable whether new commits would be automatically added to an open pull request or not.

      If not, Stash would not automatically add new commits to the open pull request but would put those commits into some queue (or something like that). From there, selected commits could be explicitly added to a new pull request. This would prevent that new aspects which might be introduced by further commits would "slip" into existing reviews although those aspects should be discussed in separate reviews.

      Rationale

      We have feature branches that typically live for a couple of days (up to one or even two weeks - they are created via Stories in JIRA Agile). At the same time, we encourage developers to push their daily changes every evening to enable reviewers to give swift feedback on that daily work. This again allows developers to incorporate important feedback as soon as possible (particularly, not only at the end of the Sprint).

      Ideally, the reviewer would approve such an pull request early in the morning; thus, immediately. However, sometimes the review reveals weak spots and the developer would have to make smaller fixes. For such fixing commits, it is absolutely fine to be automatically added to the open pull request - because these commits affect aspects that are already part of the pull request. For comparison: In Crucible, the developer would explicitly add these commits to the ongoing review (via smart commits - how cool is that?).

      Beyond that, frequently there are new commits that add new aspects, too - just because the story is not yet completed and thus being developed in the said feature branch and pull request, respectively. In this case, these commits should not be automatically added to the open pull request. Instead, they should be addressed in a new pull request that would explicitly cover the new aspects. Again, for comparison: In Crucible, such new commits would be added to a new review but not the existing one.

            [BSERV-4225] Disable automatic adding of new commits to existing pull request

            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3396127 ] New: JAC Suggestion Workflow 3 [ 3624214 ]
            Status Original: RESOLVED [ 5 ] New: Closed [ 6 ]
            Monique Khairuliana (Inactive) made changes -
            Workflow Original: BSERV Suggestions Workflow [ 2686911 ] New: JAC Suggestion Workflow [ 3396127 ]
            Owen made changes -
            Workflow Original: Stash Workflow [ 590183 ] New: BSERV Suggestions Workflow [ 2686911 ]
            Status Original: Closed [ 6 ] New: Resolved [ 5 ]
            Justus Pendleton (Inactive) made changes -
            Affects Version/s Original: 2.9.4 [ 37796 ]
            Issue Type Original: New Feature [ 2 ] New: Suggestion [ 10000 ]
            Priority Original: Minor [ 4 ]
            Roger Barnes (Inactive) made changes -
            Resolution New: Answered [ 9 ]
            Status Original: Needs Triage [ 10030 ] New: Closed [ 6 ]
            Roger Barnes (Inactive) made changes -
            Link New: This issue duplicates STASH-3263 [ STASH-3263 ]

            Hi Martin,

            Thanks for the suggestion. We are considering how to improve the pull request workflow around subsequent commits. We're not sure if blocking new commits is the way that we'll approach this, but we'll keep your feedback in mind.

            Roger Barnes (Inactive) added a comment - Hi Martin, Thanks for the suggestion. We are considering how to improve the pull request workflow around subsequent commits. We're not sure if blocking new commits is the way that we'll approach this, but we'll keep your feedback in mind.
            Martin Burger made changes -
            Description Original: *Background*

            We are currently evaluating whether we could replace Crucible by Stash and its Pull Request feature. So far, Stash's ability to create pull requests in combination with its Branching Model looks very promising.

            However, we stumbled upon the following issue:

            *Present Situation*

            Currently, new commits to a branch (for instance, feature branch) that is involved in an open pull request (for instance, from that feature branch to the main development branch) are _automatically_ added to that open pull request.

            *Feature Request*

            It should be configurable whether new commits would be automatically added to an open pull request or not.

            If not, Stash would not automatically add new commits to the open pull request but would put those commits into some queue (or something like that). From there, selected commits could be explicitly added to a new pull request. This would prevent that new aspects which might be introduced by further commits would "slip" into existing reviews although those aspects should be discussed in separate reviews.

            *Rationale*

            We have feature branches that typically live for a couple of days (up to one or even two weeks - they are created via Stories in JIRA Agile). At the same time, we encourage developers to push their daily changes every evening to enable reviewers to give swift feedback on that daily work. This again allows developers to incorporate important feedback as soon as possible (particularly, not only at the end of the Sprint).

            Ideally, the reviewer would approve such an pull request early in the morning; thus, immediately. However, sometimes the review reveals weak spots and the developer would have to make smaller fixes. For such fixing commits, it is absolutely fine to be automatically added to the open pull request - because these commits affect aspects that are already part of the pull request. For comparison: In Crucible, the developer would explicitly add these commits to the ongoing review (via smart commits - how cool is that?).

            Beyond that, frequently there are new commits that add new aspects, too - just because the story is not yet completed and thus being developed in the said feature branch and pull request, respectively. In this case, these commits should _not_ be automatically added to the open pull request. Instead, they should be addressed in a new pull request that would explicitly cover the new aspects. Again, for comparison: In Crucible, such new commits would be added to a new review but not the an existing one.
            New: *Background*

            We are currently evaluating whether we could replace Crucible by Stash and its Pull Request feature. So far, Stash's ability to create pull requests in combination with its Branching Model looks very promising.

            However, we stumbled upon the following issue:

            *Present Situation*

            Currently, new commits to a branch (for instance, feature branch) that is involved in an open pull request (for instance, from that feature branch to the main development branch) are _automatically_ added to that open pull request.

            *Feature Request*

            It should be configurable whether new commits would be automatically added to an open pull request or not.

            If not, Stash would not automatically add new commits to the open pull request but would put those commits into some queue (or something like that). From there, selected commits could be explicitly added to a new pull request. This would prevent that new aspects which might be introduced by further commits would "slip" into existing reviews although those aspects should be discussed in separate reviews.

            *Rationale*

            We have feature branches that typically live for a couple of days (up to one or even two weeks - they are created via Stories in JIRA Agile). At the same time, we encourage developers to push their daily changes every evening to enable reviewers to give swift feedback on that daily work. This again allows developers to incorporate important feedback as soon as possible (particularly, not only at the end of the Sprint).

            Ideally, the reviewer would approve such an pull request early in the morning; thus, immediately. However, sometimes the review reveals weak spots and the developer would have to make smaller fixes. For such fixing commits, it is absolutely fine to be automatically added to the open pull request - because these commits affect aspects that are already part of the pull request. For comparison: In Crucible, the developer would explicitly add these commits to the ongoing review (via smart commits - how cool is that?).

            Beyond that, frequently there are new commits that add new aspects, too - just because the story is not yet completed and thus being developed in the said feature branch and pull request, respectively. In this case, these commits should _not_ be automatically added to the open pull request. Instead, they should be addressed in a new pull request that would explicitly cover the new aspects. Again, for comparison: In Crucible, such new commits would be added to a new review but not the existing one.
            Martin Burger created issue -

              Unassigned Unassigned
              cab8b017aa61 Martin Burger
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: