Thanks it34. We did some work previously in 5.2, it sounds like you've already got that.

We are on 5.5.0 right now, upgrading shortly (had to move some stuff around re disk space which is why we aren't on latest.

it34, could you confirm what version of Bitbucket Server you're running?

it34, if you're asking whether it's ok to run git gc, it's not recommended. git gc does some good things (as we know), but it also does some things that Bitbucket's hosting needs prefer not to happen (and I must admit I don't have the exact details to hand, so I could be understating this). Instead, Bitbucket takes care of GC operations itself, calling lower level git functions to ensure the good changes happen, but not the less good ones.

All that said, it's fair to say this arrangement could be made better, and we are looking at making some improvements.

@roger.barnes Do you think it would be run `git gc` on every on repo? 

find . -maxdepth 1 -type d \( ! -name . \) -exec bash -c "cd '{}' && git gc" \;

in the /shared/data/repositories directory? I ran it on a few repos and saved a decent amount of space already. 

Our use case is that rarely updated but highly fragmented git repos will not be garbage collected. This increases the footprint (size) of the repository, and greatly increases the time and space necessary for backups, especially with relatively high latency NAS filestores.

Thanks Balazs for clarifying.

As I suggested previously, I don't think this is something we'll add in the near future. We will however, continue to be mindful of git performance and consider solutions should a recurring problem emerge.

I don't really know how often we experience this or how long delay it causes, since it is always someone else experiencing it. (I do know that when my own local clone does an auto-gc, it takes about 3 mins, so my educated guess is that the server would do it in about 20-40 sec.) I think an optional plugin would probably be the right way of solving this problem, since only big repos (= long GC) with many users (=frequent changes) are impacted in a noticeable way.

Hi basz, could you elaborate on how often you experience this and how much longer the operation takes? It's unlikely that we'd build scheduled GC in, but perhaps there are some alternatives we can explore once we better understand your situation.

Yes, auto gc will be disabled for a repository as soon as it has forks and all the repositories that are forks.