Derrick Stolee <[email protected]> writes: > On 7/1/2019 2:35 PM, Junio C Hamano wrote: >> Jeff King <[email protected]> writes: >> >>>> First, we create a (temporary) merge commit of both branches (M3) >>>> >>>> ------------ >>>> R1---R2---R3---R4---R5---R6---R7---M3 >>>> \ \ \ / >>>> F1---F2---M1---F3---F4---M2---F5 >>>> ------------ >>>> > ... >> If M3 merge is always easier to manage than incremental stepwise >> rebase of the topic, then doing the "git merge --reverse-squash" >> would be a saner interface and also conceptually simpler. > > I agree that this would be a better way to expose this behavior, > and likely the implementation could be very clean.
What I was sort-of hoping to get comments on was actually something else. Would there be cases where the merge M3 gets unmanageably complex even if rebasing the feature commits one by one is relatively simple (and how often would that happen)? "merge --squash" would not work well (and extending the command to merge in a different direction would not help) in such a situation, but "rebase -i" would work much better (and "imerge" would, too).
