On Wed, Jun 3, 2009 at 12:39 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "David E. Wheeler" <da...@kineticode.com> writes: >> Does that make sense? > > Maybe, but it still seems messy, brute force, and error-prone. > > I can't escape the feeling that we're missing something basic here. > It's allegedly one of git's great strengths that it allows you to easily > and quickly switch your attention among multiple development branches.
Well as long as the development branches are all "compatible" in the sense that you don't nee to reconfigure and rebuild everything when you switch then yes. Doing git-checkout to switch branches will work fine for branches created to work on new code or review patches. I really don't see what you mean by messy or brute force or error-prone with regards to keeping a separate clone for each major release. It's basically equivalent to having a CVS checkout for each major release which you do now. The main difference is that commit becomes a two step process -- commit to your repository, then push to the public repository. That's three steps if you include the add but I suspect you're going to be doing git-commit -a most of the time. There's an advantage that you can commit several changes to your local repo and push them all to the public repo together. That might be good if you have, for example, a bug fix which requires an api change elsewhere. You might want two separate commit messages and the ability to merge one of them forward or back separately but not want to put them in the public repo until both are available. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers