Re: managing git disk space usage

On Wed, Jul 21, 2010 at 12:39, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.

Yeah, that's the way I work with some projects at least.

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

Nope, the deal was definitely that we stick to the current workflow.

Yes, this means we can't use git cherry-pick or similar git-specific
tools to make life easier. But it shouldn't make life harder than it
is *now*, with cvs.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/