7 ms·

Do you mean `git branch --contains` or `git branch -vv`? There are many options to `git branch` that cause Git to be very slow. The commit-graph feature in gen

by stolee 8y ago

Do you mean `git branch --contains` or `git branch -vv`? There are many options to `git branch` that cause Git to be very slow. The commit-graph feature in general will make these faster by reducing time spent parsing commits. You can compute a commit-graph right now if you have Git 2.18 installed: https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/ https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar... Generation numbers will make these operations much faster in Git 2.19. Here are the related commits: `git branch --contains`: https://github.com/git/git/commit/f9b8908b85247ef60001a683c281af0080e9ee77 https://github.com/git/git/commit/f9b8908b85247ef60001a683c2... `git tag --contains`: https://github.com/git/git/commit/819807b33f820dc17d96f043747daf18c5e38516 https://github.com/git/git/commit/819807b33f820dc17d96f04374...

jwilk 8y ago
On HN: https://news.ycombinator.com/item?id=17408985 https://news.ycombinator.com/item?id=17408985
kanox 8y ago
A long time ago I made an alias always passes -v to git branch and this is the problem: on large repos it can take a long time to compute the "ahead X, behind Y" information. It can be fixed by aliasing to some git branch --format without %(upstream:track) Those numbers not really useful interactively when very large, for example it doesn't help to print that one of my branches is "behind 132132". Maybe git could print "ahead 7, behind 1000+" for old stale branches stuff? This way it would limit the number of commits examined.
- stolee 8y ago
  Earlier this year, we considered similar changes to the ahead/behind calculation in 'git status'. We concluded that there is no good way to provide partial information. Specifically, you can't say "10 ahead" without walking everything you are behind to find all merge-bases. That "10" you found could become smaller by walking more of the other set. We instead opted to not calculate that information as often. Here is my reply to the thread on-list that summarizes why I think this direction is futile: https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/t/#m976950a5c61dd2c9f12bdcd7c433344da473698f https://public-inbox.org/git/20180108154822.54829-1-git@jeff... This ahead/behind calculation is in a lot of places, including 'git fetch' where it checks if each ref update was a forced update (checks if the new ref value has the old ref value in its history). For our version of Git that ships with GVFS, we added an option to skip this check, providing a significant speedup to users fetch times: https://github.com/Microsoft/git/commit/9616c7da3141f539a4254748dedaf3db9d39687b https://github.com/Microsoft/git/commit/9616c7da3141f539a425...

by stolee 8y ago

jwilk 8y ago

On HN: https://news.ycombinator.com/item?id=17408985 https://news.ycombinator.com/item?id=17408985

kanox 8y ago

A long time ago I made an alias always passes -v to git branch and this is the problem: on large repos it can take a long time to compute the "ahead X, behind Y" information. It can be fixed by aliasing to some git branch --format without %(upstream:track) Those numbers not really useful interactively when very large, for example it doesn't help to print that one of my branches is "behind 132132". Maybe git could print "ahead 7, behind 1000+" for old stale branches stuff? This way it would limit the number of commits examined.

stolee 8y ago
Earlier this year, we considered similar changes to the ahead/behind calculation in 'git status'. We concluded that there is no good way to provide partial information. Specifically, you can't say "10 ahead" without walking everything you are behind to find all merge-bases. That "10" you found could become smaller by walking more of the other set. We instead opted to not calculate that information as often. Here is my reply to the thread on-list that summarizes why I think this direction is futile: https://public-inbox.org/git/20180108154822.54829-1-git@jeffhostetler.com/t/#m976950a5c61dd2c9f12bdcd7c433344da473698f https://public-inbox.org/git/20180108154822.54829-1-git@jeff... This ahead/behind calculation is in a lot of places, including 'git fetch' where it checks if each ref update was a forced update (checks if the new ref value has the old ref value in its history). For our version of Git that ships with GVFS, we added an option to skip this check, providing a significant speedup to users fetch times: https://github.com/Microsoft/git/commit/9616c7da3141f539a4254748dedaf3db9d39687b https://github.com/Microsoft/git/commit/9616c7da3141f539a425...