> The bug section in rebase's documentation does mention that "attempts > to reorder commits tend to produce counterintuitive results", which I > think serves as a fairly good warning saying "reorder at your own > risk". True. > Also, if we do a "rebase-i-p A1", the C1 branch will appear in > the todo list. Hm, good point. > There shouldn't be any topo-reordering unless the user explicitly > changes the order of the commit. The user is faced with the same > limitations (and bugs) as rebase-i-p'ing D1, so we shouldn't have to > handle the C1 case any different. rebase is perfectly capable of > handling the D1 case, just as how the C1 case is handled. We're only > running into this issue because we're trying to filter out C1 when > rebase-i-p'ing B1. Okay, that makes sense. I agree with you then, with the behavior of "rebase-i-p A1" plus the disclaimer in the docs warrants C1 showing up, C1 should be in the todo list for "rebase-i-p B1" as well. ...I can think of cases where personally I'd want to only move around commits on the first-parent line, e.g. even in the case of "rebase-i-p A1", to have less noise (C1 and any others on its branch) in the todo, but at that point it sounds like I'm projecting behavior onto rebase-i-p that isn't actually there. - 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