Hi Uwe, On 26/05/21 17.09, Uwe Kleine-König wrote:
Hello, I have a kernel topic branch containing 4 patches on top of Linux v5.4. (I didn't speak to the affected customer, so I cannot easily share the patch stack. If need be I can probably anonymize it or ask if I can publish the patches.) It rebases clean on v5.10: $ time git rebase v5.10 Performing inexact rename detection: 100% (36806539/36806539), done. Performing inexact rename detection: 100% (36806539/36806539), done. Performing inexact rename detection: 100% (36806539/36806539), done. Performing inexact rename detection: 100% (36806539/36806539), done. Successfully rebased and updated detached HEAD. real 3m47.841s user 1m25.706s sys 0m11.181s If I start with the same rev checked out and explicitly specify the merge base, the rebase process is considerably faster: $ time git rebase --onto v5.10 v5.4 Performing inexact rename detection: 100% (36806539/36806539), done. Performing inexact rename detection: 100% (36806539/36806539), done. Performing inexact rename detection: 100% (36806539/36806539), done. Performing inexact rename detection: 100% (36806539/36806539), done. Successfully rebased and updated detached HEAD. real 1m20.588s user 1m12.645s sys 0m6.733s Is there some relevant complexity in the first invocation I'm not seeing that explains it takes more than the double time? I would have expected that git rebase v5.10 does the same as: git rebase --onto v5.10 $(git merge-base HEAD v5.10) . (FTR: $ time git merge-base HEAD v5.10 219d54332a09e8d8741c1e1982f5eae56099de85 real 0m0.158s user 0m0.105s sys 0m0.052s , 219d5433 is v5.4 as expected. $ git version git version 2.29.2 That's from the Debian package 1:2.29.2-1~bpo10+1 on a Debian 10 box.) Best regards Uwe
Can you reproduce your findings with latest version (v2.32.0-rc1) please? -- An old man doll... just what I always wanted! - Clara
