git rebase-update is too slow, runs git prune --expire 2.weeks.ago once per branch |
|||
Issue descriptionI use "git rebase-update" to pull the latest git changes into all of my branches and I typically have four to six branches. This has never been fast but recently it has been *incredibly* slow. Monitoring with procexp.exe makes the problem obvious. Once per branch "git rebase-update" runs "git gc --auto". This then runs "git reflog expire --all" which takes about twelve seconds, and then "git prune --expire 2.weeks.ago" which takes about 120 seconds. So, with 5 branches this takes 660 seconds (eleven minutes) for the auto gc step alone. The process hierarchy (parent at the top, child at the bottom) for the "git prune" invocations is shown here: > C:\src\depot_tools\python276_bin\python.exe C:\src\depot_tools\git_rebase_update.py > C:\Windows\system32\cmd.exe /c C:\src\depot_tools\git.bat -c color.ui=never rebase --onto origin/master db346b18cb3a494e21d2c4662641eb33e1584212 truncation > C:\src\depot_tools\git-2.8.3-64_bin\cmd\git.exe -c color.ui=never rebase --onto origin/master db346b18cb3a494e21d2c4662641eb33e1584212 truncation > git.exe -c color.ui=never rebase --onto origin/master db346b18cb3a494e21d2c4662641eb33e1584212 truncation > C:\src\depot_tools\git-2.8.3-64_bin\usr\bin\sh.exe C:\src\depot_tools\git-2.8.3-64_bin\mingw64/libexec/git-core\git-rebase --onto origin/master db346b18cb3a494e21d2c4662641eb33e1584212 truncation > C:\src\depot_tools\git-2.8.3-64_bin\usr\bin\sh.exe C:\src\depot_tools\git-2.8.3-64_bin\mingw64/libexec/git-core\git-rebase --onto origin/master db346b18cb3a494e21d2c4662641eb33e1584212 truncation > C:\src\depot_tools\git-2.8.3-64_bin\mingw64\libexec\git-core\git.exe gc --auto > git prune --expire 2.weeks.ago A more truncated/readable version is here: > python.exe git_rebase_update.py > cmd.exe /c git.bat -c color.ui=never rebase --onto origin/master <commit-id> truncation > C:\src\depot_tools\git-2.8.3-64_bin\cmd\git.exe -c color.ui=never rebase --onto origin/master <commit-id> truncation > git.exe -c color.ui=never rebase --onto origin/master <commit-id> truncation > sh.exe git-rebase --onto origin/master <commit-id> truncation > sh.exe git-rebase --onto origin/master <commit-id> truncation > git.exe gc --auto > git prune --expire 2.weeks.ago Running "git gc --auto" once per rebase-update seems excessive. Running it once per branch per rebase-update is clearly too much. Possible solutions would include disabling auto gc while running rebase-update and then explicitly running it once, or only running it once if it hasn't been run on that repo in the last week or so.
,
Sep 4 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 5 2017
I disabled auto gc some time ago (git config --global gc.auto) which I think resolved this issue for me, but that then causes new problems because if "git gc" isn't run occasionally then "git cl upload" performance degrades - it was taking three minutes for me. Manually running "git gc" shaved two minutes off of "git cl upload". The best way to resolve this may be to disable gc.auto when starting the script and then restore it at the end, although doing that robustly is likely to be tricky.
,
Oct 19
|
|||
►
Sign in to add a comment |
|||
Comment 1 by benhenry@chromium.org
, Sep 1 2016