Re: Are binary xdeltas only used if you use git-gc?

From: Nicolas Pitre <nico@cam.org>
Date: Oct 31, 2008, 19:47 UTC
Message-ID: <alpine.LFD.2.00.0810311531540.13034@xanadu.home>
In-Reply-To: <f1d2d9ca0810310416n1e9f3700if49951a05cae9a37@mail.gmail.com>

On Fri, 31 Oct 2008, Thanassis Tsiodras wrote:

> Actually, after using git-gc, git-repack isn't really needed...
> git-gc identifies that the two files are very similar and re-deltifies
> (see the du -s -k outputs in the original mail, after git-gc we have
> in fact lower usage than the first commit).

git-gc does call git-repack already. In fact, git-gc is only a convenience wrapper for a couple maintenance commands.

> My question is basically...
> (a) why doesn't git detect this during commit and needs a git-gc

Because we want commit operations to be fast. One of many usage scenarios for git is to apply a large amount of patches in one go, meaning many commits per second. The gc operation is potentially long, can be done unfrequently and deferred any time, like when you don't have to wait for it.

> (b) whether after git-gc I would have seen the massive difference
> during a subsequent git-push or not

No. A push does create a pack with best size reduction already, whether or not your local or remote repositories are already packed. The only advantage for having your local repository packed is in the time required to create that same pack to be pushed.

As mentioned already, you should consider the --thin switch if you are pushing over a slow link. If the remote repository already has necessary objects then all the pushed pack will contain is all deltas.

The reason why --thin is not activated by default is because most people do pulls from a central server and only few people do pushes to such a server, and while thin packs do reduce the transmission size they do create slightly bigger packs on the receiving end which is best avoided on a busy server.

Nicolas