Re: [AMBER-Developers] Git server very slow ...

From: Jason Swails <>
Date: Tue, 28 Jan 2014 21:47:51 -0500

On Tue, Jan 28, 2014 at 5:32 PM, Ross Walker <> wrote:

> Seems to be good:
> 14:31:32 up 132 days, 21:44, 1 user, load average: 0.00, 0.01, 0.00
> And network checks out good. I suspect it is your end. That said a git
> pull after all these changes could be many gigabytes if you haven't
> updated for quite a while. If you are very out of date with no local
> changes it might actually quicker to do a git clone to a new directory.

Actually a git clone will never be faster. Git is very good at minimizing
the amount of data that it transfers, to the extent that a pull immediately
following a large merge is actually very cheap. The reason is that your
local git repository has all of the history for each branch on the remote,
and the merge is simply another (small if there are conflicts, otherwise
empty) commit. The only real time-consuming part of the pull will be git
writing new files resulting from the large merge (use a SSD and this
becomes fast too). Even if you have a tree a couple years out of date a
pull would still be much better (since most of the history and most of the
files come from well before then).

If you want a 'clean checkout', the best thing to do is to run the commands

git clean -fxd
git checkout .
git pull

This minimizes the load on the git server significantly, the required
bandwidth, and the amount of time it takes to complete an update. Moral of
the story -- never clone unless you must. [1]

Just a bit of git advice,

[1] Words are all well and good, demonstrations are better.

If I start from a fresh repository that knows only of one branch whose head
is at db79cad78912 (one of the last commits in 2011), a "git fetch amber"
that synchs the main amber repo takes 1 minute 30 seconds, followed by a
"git merge amber/master" that takes 30 seconds (these two commands are
exactly equal to a git pull). The data transferred over the network is
487.5 MB. (The demo output is available here:

Compare that to a fresh clone on the same disk from the same machine that
takes 7 minutes to transfer 1.35 GB. (The demo output is available here: If the tree was last updated, say, even 6
months ago the pull would be that much better than the clone.
Jason M. Swails
Rutgers University
Postdoctoral Researcher
AMBER-Developers mailing list
Received on Tue Jan 28 2014 - 19:00:03 PST
Custom Search