On 11-06-18 11:17 AM, Stephen Haberman wrote:
Letting C1 into the todo would mean having to explain to the user why
some of their reorderings worked and others didn't.
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".
Also, if we do a "rebase-i-p A1", the C1 branch will appear in the todo
list. A while ago I actually ran into this scenario, and I want to
squash a commit onto the C1 branch, which I can't if I simply choose B1
as the base. To workaround it, I just made A1 the base so that the C1
branch will appear in the todo for me to squash upon. Otherwise, doing
the squash onto C1 manually would've involved several more steps.
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.
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.
--
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