Re: managing git disk space usage

At 2010-07-20 13:04:12 -0400, robertmhaas(at)gmail(dot)com wrote:
>
> 1. Clone the origin. Then, clone the clone n times locally. This
> uses hard links, so it saves disk space. But, every time you want to
> pull, you first have to pull to the "main" clone, and then to each of
> the "slave" clones. And same thing when you want to push.

If your extra clones are for occasionally-touched back branches, then:

(a) In my experience, it is almost always much easier to work with many
branches and move patches between them rather than use multiple clones;
but

(b) You don't need to do the double-pull and push. Clone your local
repository as many times as needed, but create new git-remote(1)s in
each extra clone and pull/push only the branch you care about directly
from or to the remote. That way, you'll start off with the bulk of the
storage shared with your main local repository, and "waste" a few KB
when you make (presumably infrequent) new changes.

But that brings me to another point:

In my experience (doing exactly this kind of old-branch-maintenance with
Archiveopteryx), git doesn't help you much if you want to backport (i.e.
cherry-pick) changes from a development branch to old release branches.
It is much more helpful when you make changes to the *oldest* applicable
branch and bring it *forward* to your development branch (by merging the
old branch into your master). Cherry-picking can be done, but it becomes
painful after a while.

See http://toroid.org/ams/etc/git-merge-vs-p4-integrate for more.

-- ams