Open piefel opened 8 months ago
This sounds like a bug. SPR actually has logic to handle reordering of commits. Everything you did is actually (or should be) a-ok. I will try to recreate this case and see what the root cause it.
Today, I again ran into the situation where I had to reorder commits. It worked fine.
What was different today: I am on a branch, last time I was on develop
, the merge target. Perhaps, hmm, I changed things the last time without calling git spr update
in between, today I certainly did not.
Hi,
Today, I had 2 commits and reordered them. After updating, git spr closed the PR's that where open before and created new PR's.
This is not beneficial, as the older PR's had some comments on them that I still wanted to address. Is this the way git spr works ? I would be better to keep the PR's and just change the merge branch.
I had a small stack with commits A, B, and C like this:
Then I noticed a small issue that could (should?) have been commit D, but instead it was so obviously semantically part of A that I decided to change the two files and use
git amend
, which works splendidly:However, since the unit of PR is commit, not set of commits, each commit must be valid individually. Which is good, just sometimes uncomfortable. Problem was, my fix in A’ depended on something in C, so the Github checks on A’ failed. Instead of just skipping them or trying to amend again somehow and perhaps use that D commit after all, I decided on a nice and clean solution with
git rebase --interactive
, just reordering the commits:Well, I guess I did something forbidden here and just have myself to blame. Anyway,
git spr update
didn’t like that too well and spew out a stacktrace which I have to anonymize a bit:(Interesting paths embedded in the Go binaries. Make mental note to look out for this when using Go myself.)
Also note “github update 647 : Commit message for A’” which updated the existing PR, and “github create 650 : Commit message for B” which tried a new PR instead of changing the existing 648.
So, could I have done it cleanly with spr? If not, would it be possible to implement? Or shall I submit a proposal for a warning in the README?