On Wed, Jul 21, 2010 at 6:17 AM, Abhijit Menon-Sen <a...@toroid.org> wrote: > At 2010-07-20 13:04:12 -0400, robertmh...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers