Alban Gruin <alban.gruin@xxxxxxxxx> writes: > One of the first things done by the interactive rebase is to make a todo > list. This requires knowledge of the commit range to rebase. To get > the oid of the last commit of the range, the tip of the branch to rebase > is checked out with prepare_branch_to_be_rebased(), then the oid of the > HEAD is read. On big repositories, it's a performance penalty: the user > may have to wait before editing the todo list while git is extracting the > branch silently (because git-checkout is silenced here). After this, > the head of the branch is not even modified. Hmph. One curious thing in the above is why this is specific to "rebase -i". The need to know the commit range to rebase is shared across any rebase backend, and it would be the most natural to parse the optional second argument (i.e. the branch or the commit to rebase) before builtin/rebase.c dispatches to a specific rebase backend, wouldn't it? So, the question is why a normal "rebase" does not need the same fix? If the answer is "rebase in general was fine without extra checkout, but 'rebase -i' was doing an unnecessary checkout" (or any other answer) that is something that would help future readers to record in the commit log message. Thanks.
