From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Abhijit Menon-Sen <ams(at)toroid(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: managing git disk space usage |
Date: | 2010-07-21 10:39:28 |
Message-ID: | AANLkTinYAttv7-NdUzWg9VUhxB7EUuSdruuJbqwZfqDn@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen <ams(at)toroid(dot)org> wrote:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-07-21 10:42:03 | Re: managing git disk space usage |
Previous Message | KaiGai Kohei | 2010-07-21 10:35:58 | Re: leaky views, yet again |