Pull request workflow - changes post review and multiple heads

Sean Farley sean at farley.io
Mon Jul 6 21:06:28 UTC 2015


Jaikiran Pai <jai.forums2013 at gmail.com> writes:

> Hello everyone,
>
> We have a workflow within our team which is as follows:
>
> - There's an "upstream" repo "foo" which is shared by the team. Only 
> select members have push access to it
> - There are N developers in the team, each one working against a forked 
> copy of the upstream repo, under their own account.
> - Each of them commit to their own repos and issue a pull request once 
> they have their feature/bug-fix ready for review.
> - A reviewer goes through the commit "A" in the pull request and 
> suggests any changes that are needed
> - The developer then fixes those issues in the pull request and adds a 
> new commit "B" to the pull request.
>
> What we ideally want to do is "fold" A and B into one commit and have it 
> pushed to the "upstream". It's straightforward to ask the developer to 
> fold those 2 commits and *force* push the changesets to this own repo 
> (which by the way isn't shared). The force push is needed since the fold 
> ends up creating a new head. Of course, the (redundant) head can then be 
> manually closed via a "hg commit --close-branch" but is there a better 
> way of dealing with this? Perhaps auto-closing the redundant head while 
> dealing with the fold?
>
> The end goal we are trying to achieve is having the commits from most of 
> the developers come through via pull requests and once the changes are 
> reviewed and approved, have them committed as one (in most cases) 
> logical commits.

This is one of the goals of changeset evolution, so in a future world,
this use-case will be taken care of. Out of curiosity, is this repo on
Bitbucket?



More information about the Mercurial mailing list