> In commit a4f25e3, we could already rebase B1 and squash F1 onto D1, > while reusing C1 and recreating the merge. That means we could > already pass t3411.2if we adjusted the todo-list to account for the > extra "pick C1" line. You're right. I was wrong about that. > Slightly off-topic, but I believe the branches will remain intact as > long as the branch commits remain in the same topo-order relative to > each other in the todo-list. If in topo-order, yeah, I guess that is right. > i.e. git will be confused if we try to move a commit from one branch > into the other. Right. If I do `rebase -i -p B1` and in the todo put C1 after F1, I get a fatal message that E1 cannot be cherry picked. Given rebase-i-p's limited ability to reorder graphs, e.g. the error above, my understanding was that, when -p is used, only first-parent changes should be in the todo. This straight line, non-graph list does limit what the user can do, but, AFAIK, the benefit is that rebase-i-p can then actually handle any given reordering of the todo. Letting C1 into the todo would mean having to explain to the user why some of their reorderings worked and others didn't. Or else making rebase-i-p smart enough to handle all cases. Which, IIRC, was something considered unlikely just given the fact that todo is flat and there isn't a way for the user to express topo reorderings. At the time, there was talk of another rewriting tool that would use marks and other hints to handle graphs and it was considered what, if anything, would eventually handle complex rewrites like this. I think that Jeff's use case of rebase-i-p'ing C1, which is not on the first-parent list of commits, should be an error as it delves into territory (topo reordering) that rebase-i-p can't fully handle. (If -p isn't used, just regular rebase, everything is being flattened, so there is no concern of topo reordering, so things are a lot simpler and C1 can/should be in the list.) - Stephen -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html