Closed Huxpro closed 2 years ago
This is expected behavior, and needs to be documented better in the readme so it's less surprising. When you merge, the top pr is rebased on top of master, and then merged. All the commits will be merged at once. Then the rest of the prs are closed.
Some related discussion: #209 #227
I have been very happy with spr, but this is really not the workflow I was hoping for. I might use spr slightly differently than intended and having PR's merged individually is much more fitting for me.
I have a large refactoring effort, and there is always substantial delay between I make a contribution to it being reviewed. I would like to build on previous changes to the review delay does not hold me back, and merge the commit one-by-one when they have been reviewed because they are atomic and at times not directly related.
The merge --upto method works, but it would be nice to just have it be a setting.
SPR has changed my daily workflow for the better, and I would love to help in any way I can.
@anagrius : spr was designed for the exact use case you are experiencing, where you want to keep working on features that build on top of other features, without having to wait until the base feature merges. Just to clarify, when you run 'git spr merge', all the prs that are ready to be merged in the stack are merged. I sometimes have stacks that grow to 10-15 prs, and merging them one by one would be a pain, so personally I like the ability to merge them all at once in one shot. Having said that, you are not alone in wanting to merge prs one by one, for a similar feature enhancement request see #231
@anagrius - how about we add a flag --one that only merges one pr?
Added a new flag --count or -c. Now this can be easily achieved with:
git spr merge -c 1
Is this an expected behavior that when you run
git spr merge
to merge a stack, only the top PR is actually "merged" and others are only "closed"? This seems to be very counter intuitive.