Re: [Request] Git export with hardlinks

[Jeff King <peff@peff.net>]

On Wed, Feb 06, 2013 at 04:19:07PM +0100, Thomas Koch wrote:

> I'd like to script a git export command that can be given a list of already 
> exported worktrees and the tree SHA1s these worktrees correspond too. The git 
> export command should then for every file it wants to export lookup in the 
> existing worktrees whether an identical file is already present and in that 
> case hardlink to the new export location instead of writing the same file 
> again.
> 
> Use Case: A git based web deployment system that exports git trees to be 
> served by a web server. Every new deployment is written to a new folder. After 
> the export the web server should start serving new requests from the new 
> folder.
> 
> It might be possible that this is premature optimization. But I'd like to 
> learn more Python and dulwich by hacking this.
> 
> Do you have any additional thoughts or use cases about this?

If you can handle losing the generality of N deployments, you can do it
in a few lines of shell.

Let's assume for a moment that you keep two trees at any given time:
the existing tree being used, and the tree you are setting up to deploy.
To save space, you want the new deployment to reuse (via hardlinks) as
many of the files from the old deployment as possible.

So imagine you have a bare repository storing the actual data:

  $ git clone --bare /some/test/repo repo.git
  $ du -sh *
  49M     repo.git

and then you have one deployment you've set up previously by checking
out the repo contents:

  $ export GIT_DIR=$PWD/repo.git
  $ mkdir old
  $ (cd old && GIT_WORK_TREE=$PWD git checkout HEAD)
  $ du -sh *
  24M     old
  49M     repo.git

So a full checkout is 24M. For the next deploy, we'll start by asking
"cp" to duplicate the old, using hard links:

  $ cp -rl old new
  $ du -sh *
  24M     new
  768K    old
  49M     repo.git

and we use hardly any extra space (it should just be directory inodes).
And now we can ask git to make "new" look like some other commit. It
will only touch files which have changed, so the rest remain hardlinked,
and we use only a small amount of extra space:

  $ (cd new && GIT_WORK_TREE=$PWD git checkout HEAD~10)
  $ du -sh *
  24M     new
  1.3M    old
  49M     repo.git

Now you point your deployment at "new", and you are free to leave "old"
sitting around or remove it at your leisure. You save space while the
two co-exist, and you saved the I/O of copying any files from "old" to
"new".

This breaks down, of course, if you want to keep N trees around and
hard-link to whichever one has the content you want. For that you'd have
to write some custom code.

-Peff