-
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