Re: managing git disk space usage

On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen <ams@toroid.org> wrote:
> At 2010-07-20 13:04:12 -0400, robertmhaas@gmail.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.

Ah, that is clever.  Perhaps we need to write up directions on how to do that.

> 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.

Well, per previous discussion, we're not going to change that at this
point, or maybe ever.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company