managing git disk space usage
in [PgSql]
|
From: Robert Haas on 21 Jul 2010 06:39 On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen <ams(a)toroid.org> wrote: > At 2010-07-20 13:04:12 -0400, robertmhaas(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 21 Jul 2010 06:42 On Wed, Jul 21, 2010 at 12:39, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen <ams(a)toroid.org> wrote: >> At 2010-07-20 13:04:12 -0400, robertmhaas(a)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. 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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Abhijit Menon-Sen on 21 Jul 2010 06:17 At 2010-07-20 13:04:12 -0400, robertmhaas(a)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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Abhijit Menon-Sen on 21 Jul 2010 06:56 At 2010-07-21 06:39:28 -0400, robertmhaas(a)gmail.com wrote: > > Perhaps we need to write up directions on how to do that. I'll write them if you tell me where to put them. It's trivial. > Well, per previous discussion, we're not going to change that at this > point, or maybe ever. Sure. I just wanted to mention it, because it's something I learned the hard way. It's also true that back-porting changes is a bigger deal for Postgres than it was for me (in the sense that it's an exception rather than a routine activity), and individual changes are usually backported as soon as, or very soon after, they are committed; so it should be less painful on the whole. Another point, in response to Magnus's followup: At 2010-07-21 12:42:03 +0200, magnus(a)hagander.net wrote: > > Yes, this means we can't use git cherry-pick or similar git-specific > tools to make life easier. No, that's not right. You *can* use cherry-pick; in fact, it's the sane way to backport the occasional change. What you can't do is efficiently manage a queue of changes to be backported to multiple branches. But as I said above, that's not exactly what we want to do for Postgres, so it should not matter too much. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 21 Jul 2010 06:57 On Wed, Jul 21, 2010 at 6:56 AM, Abhijit Menon-Sen <ams(a)toroid.org> wrote: > At 2010-07-21 06:39:28 -0400, robertmhaas(a)gmail.com wrote: >> >> Perhaps we need to write up directions on how to do that. > > I'll write them if you tell me where to put them. It's trivial. Post 'em here or drop them on the wiki and post a link. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: [HACKERS] managing git disk space usage Next: dynamically allocating chunks from shared memory |