Re: managing git disk space usage - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: managing git disk space usage
Date
Msg-id 20100721105627.GC5198@toroid.org
Whole thread Raw
In response to Re: managing git disk space usage  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: managing git disk space usage
List pgsql-hackers
At 2010-07-21 06:39:28 -0400, robertmhaas@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@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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: antisocial things you can do in git (but not CVS)
Next
From: Robert Haas
Date:
Subject: Re: pg_config problem on Solaris 10u7 X64