Git - pushing a remote branch for a large project is really slow

Question

We\'re just moving to git at my work. We have a reasonably large project with some fairly large resources under version control (~500MB).

Today we tried to push a br

Answer 1

Can you update your post with a few things?

To get a better idea of how your project looks, please post around the top 10+ entries of the following:

git log --decorate=short --oneline --graph --all

If the large resources are binaries, then no they should not be stored in git. If those binary resources are updated then git then it has to make a complete duplicate of them internally, which the compression algorithm doesn't like, and send those up to the server. As for what to do about them, that depends on the scenario. You'll need to elaborate.

It sounds like you have several developers working on the same remote. Is this correct? If so, no developer should be committing directly to master (imho should never happen anyways). It's possible for each developer to have their own named branch. For example, developer John can create all his branches under john/<branch_name>. This will help keep the workflow clean.

Also, git doesn't work with deltas. It stores the file in its entirety each time it's changed. This may seem inefficient, but the compression used keeps size down to a minimum. And it helps checkouts and scanning log history much faster. Read the first section of Git Basics for a visualization.

Answer 2

Another factor can explain the git push poor performance:

"git push" used to check ambiguities between object-names and refnames while processing the list of refs' old and new values, which was unnecessary (as it knew that it is feeding raw object names).

See commit a4544b3 (06 Nov 2018) by Derrick Stolee (derrickstolee).
Helped-by: Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 1373999, 19 Nov 2018)}

pack-objects: ignore ambiguous object warnings

A git push process runs several processes during its run, but one includes git send-pack which calls git pack-objects and passes the known have/wants into stdin using object ids.

However, the default setting for core.warnAmbiguousRefs requires git pack-objects to check for ref names matching the ref_rev_parse_rules array in refs.c.
This means that every object is triggering at least six "file exists?" queries.

When there are a lot of refs, this can add up significantly!
I observed a simple push spending three seconds checking these paths.

This has been fixed with Git 2.20 (Q4 2018).