[ch71r22]

I'm interested, but confused. I feel like I need either a more complete example of the workflow (writing code -> reviewing -> rewriting my history -> merging) or a deeper dive into how this works.

Will the same commit ever appear in two pull requests managed by Revup?

Does this take every commit in a "topic", cherry-pick it to a Revup-managed branch under the hood, and create a pull request for that topic?

If so, how can you safely merge these branches if they differ significantly from the one that the developer is testing on? or do you just rely on continuous integration? or do you wait until all topics that share a history have passed review?

Do you run into problems where PR comments get deleted after amending the history and re-pushing?

[jerryxzhang]

>I feel like I need either a more complete example of the workflow (writing code -> reviewing -> rewriting my history -> merging) or a deeper dive into how this works.

Have you tried the tutorial? It's only missing the reviewing + merging, but that can be done in github UI just like a normal PR.

>Will the same commit ever appear in two pull requests managed by Revup?

No, github will show just the commits in that pull request but not in its target branch/pr

>Does this take every commit in a "topic", cherry-pick it to a Revup-managed branch under the hood, and create a pull request for that topic?

Yep

>If so, how can you safely merge these branches if they differ significantly from the one that the developer is testing on? or do you just rely on continuous integration? or do you wait until all topics that share a history have passed review?

One of the biggest advantages of working this way is that changes can merge as soon as each one is ready / reviewed. CI definitely helps, but mainly we rely on the author's awareness of interdependencies between their changes. It's certainly possible to get unexpected behavior, but after thousands of PRs with this workflow it hasn't caused any problems.

>Do you run into problems where PR comments get deleted after amending the >history and re-pushing?

Even after force pushing, github will still show old comments

[ch71r22]

Thank you! I'll give it a try later this week.

It's a really interesting idea. The multi-PR workflow I was used to in Facebook's Phabricator required a lot of commit reordering to get things ready for review. Having separate review branches (topics) from dev branches seems like a nice alternative.

I still think there could be something earlier or more explicit in the README to explain the general idea of cherry-picking commits from a dev branch to review branch to split out convenient independent units to review and merge separately. Without running the tutorial, I wasn't really sure that's what the goal was.

[jerryxzhang]

I've updated the descriptions to make that more clear. thanks for the feedback!