Update go-git to v4.12.0

[techknowlogick]

fixes #7248

[codecov-io]

Codecov Report

Merging #7249 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #7249      +/-   ##
==========================================
- Coverage   40.98%   40.98%   -0.01%     
==========================================
  Files         462      462              
  Lines       62585    62585              
==========================================
- Hits        25653    25648       -5     
- Misses      33571    33575       +4     
- Partials     3361     3362       +1

Impacted Files	Coverage Δ
modules/process/manager.go	76.81% <0%> (-4.35%)	⬇️
models/repo_list.go	72.08% <0%> (-1.02%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b209531...d60fd7b. Read the comment docs.

[lunny]

@filipnavara As my simple local test with gitlab-ce, gitea's homepage load time always 4000ms ~ 5000ms before merging this PR or not. It should have an improvement on performance but not very obvious.

[zeripath]

I think we're going to have to implement commit-graphs and bloom filters.

[filipnavara]

I will send PR for loading commit-graphs, the modifications are quite small now that most of the API was upstreamed. I don't know what is the best place to generate them though. As far as bloom filters go I have an experimental implementation that looked really promising in my local test but it is not very polished.

[zeripath]

I think as a start it might be sensible to tell git to use them if its version is young enough.

If the version is too old we'll probably have to update the graphs in post-receive.

We'll have to adjust any go-git based code to use information from the graphs too.

Does your implementation cope with looking in alternatives? We have moved to use shared in a lot of places and although the operations that we do in these tend not to do significant history walking they might still find some improvement.

[filipnavara]

Does your implementation cope with looking in alternatives? We have moved to use shared in a lot of places and although the operations that we do in these tend not to do significant history walking they might still find some improvement.

Not at the moment, but it would be easy to implement. I only used it for the history queries used for directory listing so far. It may help in other places but I started with the biggest bottleneck in the first place.