-
Suggestion
-
Resolution: Answered
-
None
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.
- duplicates
-
BSERV-3263 As a reviewer, I want to use comments and diffs on a pull request to clearly track iterative changes made during the review of a pull request.
- Closed
[BSERV-4225] Disable automatic adding of new commits to existing pull request
Workflow | Original: JAC Suggestion Workflow [ 3396127 ] | New: JAC Suggestion Workflow 3 [ 3624214 ] |
Status | Original: RESOLVED [ 5 ] | New: Closed [ 6 ] |
Workflow | Original: BSERV Suggestions Workflow [ 2686911 ] | New: JAC Suggestion Workflow [ 3396127 ] |
Workflow | Original: Stash Workflow [ 590183 ] | New: BSERV Suggestions Workflow [ 2686911 ] |
Status | Original: Closed [ 6 ] | New: Resolved [ 5 ] |
Affects Version/s | Original: 2.9.4 [ 37796 ] | |
Issue Type | Original: New Feature [ 2 ] | New: Suggestion [ 10000 ] |
Priority | Original: Minor [ 4 ] |
Resolution | New: Answered [ 9 ] | |
Status | Original: Needs Triage [ 10030 ] | New: Closed [ 6 ] |
Link |
New:
This issue duplicates |
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. |
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.