4 ms·

I work in a project with 50 engineers. Our git repo is 2GB plus 5GB of submodules. Git is painfully slow and I would imagine with more engineers it would become

by qznc 6y ago

I work in a project with 50 engineers. Our git repo is 2GB plus 5GB of submodules. Git is painfully slow and I would imagine with more engineers it would become unusable. For example, git-fetch takes at least a minute. To some degree we are doing it wrong like using Windows, creating too many tags, and committing binary blobs (despite LFS). Still, scaling it up by factor of two or three would not change it significantly.

gen220 6y ago
Interesting... when you say fetch, are you talking about a cold-fetch? `du -sh repo` for me is 15GB, and we don't experience the slowness you describe. If I'm checking out a branch that diverged from master 1 year ago, it takes maybe... 30 seconds? But I don't know, maybe we've cast different git-spells from you all? We don't use sub-modules, for example.
- qznc 6y ago
  I assume to some degree our Bitbucket server is slow. Not sure if Bitbucket is the culprit or our IT. One the other hand, git-status is also slow like 30 seconds. That is something I rather attribute to Windows. Doing the same inside WSL is faster. Some people invested quite some time to speed it up. So apparently it isn't some low hanging fruit.
ptsneves 6y ago
Have you considered making shallow clones? Also indeed you are doing many things that harm usability. I am surprised though you are saying you have issues with blobs even in LFS.
- qznc 6y ago
  Yes. Shallow clones and submodules do not go well together though: For shallow clones, git is setup to not track all remote branches. This can result in an error message when the submodule has not fetched the commit you want to switch to.
KerrickStaley 6y ago
I would avoid Git submodules; it seems like a fairly poorly designed feature and I'm constantly getting my submodules into a bad state (e.g. when switching branches). The alternative that has worked a lot better for me, in repos that use Bazel, is Bazel external repositories (using git_repository or http_archive). A more direct replacement that I hear is better is git subtree although I haven't used it. Also, you're probably already doing this, but make sure you're running Git on an SSD! Spinning rust will slow down VCS workloads, which are disk intensive, considerably.
- qznc 6y ago
  Yes, I use an SSD. Our next try is probably to rely more on Conan and Artifactory to download binary artifacts. In theory, that could result in similar behavior to Bazel cloud builds though not as integrated and granular.

by qznc 6y ago

gen220 6y ago

Interesting... when you say fetch, are you talking about a cold-fetch? `du -sh repo` for me is 15GB, and we don't experience the slowness you describe. If I'm checking out a branch that diverged from master 1 year ago, it takes maybe... 30 seconds? But I don't know, maybe we've cast different git-spells from you all? We don't use sub-modules, for example.

qznc 6y ago
I assume to some degree our Bitbucket server is slow. Not sure if Bitbucket is the culprit or our IT. One the other hand, git-status is also slow like 30 seconds. That is something I rather attribute to Windows. Doing the same inside WSL is faster. Some people invested quite some time to speed it up. So apparently it isn't some low hanging fruit.

ptsneves 6y ago

Have you considered making shallow clones? Also indeed you are doing many things that harm usability. I am surprised though you are saying you have issues with blobs even in LFS.

qznc 6y ago
Yes. Shallow clones and submodules do not go well together though: For shallow clones, git is setup to not track all remote branches. This can result in an error message when the submodule has not fetched the commit you want to switch to.

KerrickStaley 6y ago

I would avoid Git submodules; it seems like a fairly poorly designed feature and I'm constantly getting my submodules into a bad state (e.g. when switching branches). The alternative that has worked a lot better for me, in repos that use Bazel, is Bazel external repositories (using git_repository or http_archive). A more direct replacement that I hear is better is git subtree although I haven't used it. Also, you're probably already doing this, but make sure you're running Git on an SSD! Spinning rust will slow down VCS workloads, which are disk intensive, considerably.

qznc 6y ago
Yes, I use an SSD. Our next try is probably to rely more on Conan and Artifactory to download binary artifacts. In theory, that could result in similar behavior to Bazel cloud builds though not as integrated and granular.