Closed drewdeponte closed 10 months ago
Ok, I thought about this a bit more this weekend. I think the right thing to do is to actually check for merge commits and bail out of the command with an error. Letting the user know that a merge commit was detected and that they need to first do a gps rebase
on their stack to flatten any merge commits.
The reason I think this makes sense is because the stack is where you iterate on patches to get things into a good state prior to requesting review or integrating them. Having a merge commit in the stack goes against the linear history idea that the stack is founded around. Therefore, I think we should take the stance that users should have to git rid of (flatten out) any merge commits in the stack so that they can create linear history patch series when requesting review or integrating. And the easiest way to do that is to simply run gps rebase
as it will flatten merge commits.
This has been integrated into mainline. Therefore I am closing this issue.
When you do a
gps rebase
which simply does an interactive rebase using actualgit
it seems to look at the two parents of the merge commit and instead of copying the merge commit, it instead cherry picks the commits between that merge commit and that parents leg of the down to the common ancestor, on top of the rest of the commits from parent 0s leg.Right now when we do any command that uses our custom cherry picking it actually coppies the merge commit over, but it does so in a way that drops the parent 1 leg of commits. So you end up with a merge commit that isn't actually merging anything.
This should be addressed probably by doing what the interactive rebase dose.