Hi Junio, Le 22/01/2020 à 21:47, Junio C Hamano a écrit : > 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? > That's a problem shared by all rebases using the sequencer, so -m and -r are also affected by this. `am' is not. > 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. > So yes, the answer is that the am backend does not perform this checkout, unlike all others rebases. I will resend this patch very soon. > Thanks. > > Cheers, Alban
