Easy to read diff for chained pull requests and updated pull requests

[Richard Comblen]

I've been using Gerrit before my team moved to Stash.

Stash is much more user friendly, but I miss some features of Gerrit that are great.

Use case 1: Two chained PR

PR 1: implement server side logic for a given use case

PR 2: implement client side logic for the same use case

PR 2 needs the code of PR 1, so it includes all the commits of PR 1

With the current status of Stash (we use 3.4 for now), the diff view of PR 2 shows diff against master, and it cannot be properly reviewed until PR 1 is merged, otherwise, you see commits of both PR 1 and PR 2 in the diff view of PR 2.

In Gerrit, you see only the diff of PR 2, the only restriction is that you cannot merge it before PR 1 is merged (which is fine).

Any plan to achieve this with Stash ?

Minimalist solution would be a to be able to choose the reference branch/commit for the diff view.

Best would be to show the diff against the other PR.

Use case 2: Revisions to a PR

• Developer opens a pull request.
• Reviewer comments
• Developer updates the pull request
• Reviewer wants to see what changed, to assess if the comments were properly handled

In Gerrit, there is the notion of patch set, which is a 'version' of the pull request. In the diff view, it is possible to select against what you diff. It can be the base of the PR, or any previous patch set. It makes it super easy to see what was updated.

Solution to implement that in Stash would be either:

• Be able to pick against which commit you diff
• Create a new 'version' of the pull request each time someone pushes to the branch and allow user to choose against which 'version' to have the diff view

Is that something you would consider ?

Thanks for reading and for developing this great product!

[Dylan Piergies]

Another +1 Reviewing updates to pull requests will be very difficult without being able to choose your diff's commit range in some way.

[Chris Ortman]

+1 on this There needs to be a way to view the changes introduced by the pull request without having to click to each file In github on the files changed tab you can scroll through all the changes without having to click on a file to see just its changes. This is much more useful because very often you can scan the changes and detect where you need to focus. This functionality is more important when you have pull requests that contain small focused commits vs the 1 commit that changes 50 files and has a commit message of Fixed bug #XXXX

[Itay Neeman]

I'd like to add that we would also like this feature. We're currently using Crucible and Fisheye to do code reviews for pull requests, and Crucible has this feature by virtue of the commit range slider, which is insanely useful, as I can decide how big or small my diff is going to be. You can kind of get this in Stash by going into the diff of subsequent individual commits, but it's not the same (and obviously you can't see multiple commits at once this way).

[Richard Comblen]

You should have received an email from me. I'd be glad to share my thoughts.

[Brett]

Sorry Richard, I didn't realise this was a public question. I've removed the answer to avoid confusion, the link is internal. Would love to talk to you more about this bflower [at] atlassian com.