How do I try out a pull request before merging it?

[Rand Corbett]

This question is in reference to Atlassian Documentation: Work with pull requests

I routinely wish I could try out a pull request locally before actually merging it. (I'd rather not merge it and revert it.) The documentation says to run `git fetch && git log ..origin/master` to do this, but this isn't working for me. I have two outstanding pull requests into my master branch as I write this, but `git fetch` and `git log ..origin/master` both come back empty. If I merge a PR, then of course `git fetch` does show the new commits — but the whole point is to try them out before merging the PR, right?

In the absence of being able to do this, the best work-around I've heard of so far is to add the contributor's forked repo as a remote and pull from it directly, then throw away the changes and merge the PR if it's good. This is not an ideal solution. What's the best way to try out a PR before merging it?

[JamieA]

You can checkout the PR merge result... BBS creates refs for the result of any merge every time either the source or target ref changes, although your fetch spec won't automatically pull them. 

The box out at the bottom of this section explains how to fetch them: https://scriptrunner.adaptavist.com/latest/bitbucket/StashEventHandlers.html#_block_creation_of_out_of_date_pull_requests

The other strategy is to ensure that PRs can't be merged unless they have been rebased or merged with master. If you do this you can guarantee it will just be a copy merge, so you only need check out the PR - some more info about 2/3 down this page: http://www.adaptavist.com/w/inside-adaptavists-stash-pull-request-workflow/

[Rand Corbett]

Thanks @Jamie Echlin [Adaptavist] – I read your article and tried the suggestion (while I have an open PR #36), but it doesn't work for me:

$ git fetch origin  +refs/pull-requests/36/*:refs/remotes/origin/pull-requests/36/*
no matches found: +refs/pull-requests/36/*:refs/remotes/origin/pull-requests/36/*

Running `git ls-remote` does not show any `refs/pull-requests`; the only refs it shows are `refs/heads`.

Also tried some suggestions from this article I just found, but no luck there either:

$ git fetch origin refs/pull-requests/36/from:master
fatal: Couldn't find remote ref refs/pull-requests/36/from

$ git fetch https://bitbucket.org/{username}/{repo}/pull-requests/36
From https://bitbucket.org/{username}/{repo}/pull-requests/36
 * branch            HEAD       -> FETCH_HEAD

All of these either give me an error or fail to pull down any new commits (as far as I can tell; am I missing them somewhere locally?). What am I doing wrong here?

[JamieA]

Works for me... on BBS 4.1, but also worked previously. 

....
* [new ref] refs/pull-requests/142/from -> origin/pull-requests/142/from
* [new ref] refs/pull-requests/142/merge -> origin/pull-requests/142/merge

Maybe Atlassian support can help you

[JamieA]

ls-remote won't show them because they're not under refs/heads, afaik.

[JamieA]

Oh, are you using Cloud? My answer was for Bitbucket server, sorry, but something similar should work for Cloud, but I don't know what it is.

[Rand Corbett]

Interesting. And that's definitely the exact command you're running (modulo PR number)? You didn't do anything special to create the pull-requests ref? Looks like I should talk to support, yeah.

[Rand Corbett]

More importantly, am I missing the larger picture here? Is it really standard to just merge a PR without trying it out first? What's the standard workflow for this? I'm surprised this is such an obscure thing to do.

[JamieA]

Exactly that, but for cloud I would follow the so.com answer you found.

[JamieA]

What do mean by "trying it out"? If you mean CI build and test then that's the standard procedure, but you can only know that it will be the same as the merge results if you enforce that it's rebased or merged from the destination, and have at least one CI build, before you do the merge. That's the standard procedure here but I doubt it is everywhere.