Supercharging the Git Commit Graph IV: Bloom Filters

Re:Supercharging the Git Commit Graph IV: Bloom Filters by kanox on Tuesday July 17, 2018 @08:37AM (#17549232)

Can you make `$ git branch` fast? Because it takes 5-10 seconds for me on linux.

[ Parent | on HN ]

Re:Supercharging the Git Commit Graph IV: Bloom Filters by stolee on Tuesday July 17, 2018 @09:00AM (#17549373)

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/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/f9b8908b85247ef60001a683c2...

`git tag --contains`: https://github.com/git/git/commit/819807b33f820dc17d96f04374...

[ Parent | on HN ]

Re:Supercharging the Git Commit Graph IV: Bloom Filters by kanox on Tuesday July 17, 2018 @07:38PM (#17554468)

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.

[ Parent | on HN ]

Re:Supercharging the Git Commit Graph IV: Bloom Filters by stolee on Wednesday July 18, 2018 @06:50AM (#17557114)

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@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/9616c7da3141f539a425...

[ Parent | on HN ]

Re:Supercharging the Git Commit Graph IV: Bloom Filters by jwilk on Tuesday July 17, 2018 @12:03PM (#17550641)

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

[ Parent | on HN ]

Re:Supercharging the Git Commit Graph IV: Bloom Filters by ninkendo on Tuesday July 17, 2018 @08:40AM (#17549244)

How big of a repository? It should be a near-instantaneous operation.

I’m in a repo with 40GB in .git (hundreds of thousands of commits) and `git branch newbranch` is pretty much immediate.

[ Parent | on HN ]