On Mon, May 3, 2010 at 10:25 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> The thing we've always agreed upon is to at least start by migrating >> something that's as close to our current workflow as possible to git, >> and *then* consider changing anything in the workflow. We're not going >> to change both at once. > > Yeah. One of the main constraints in my view is retaining our current > workflow for back-patching release branches. We're not going to stop > supporting those branches, and we're not going to deal with two separate > repositories. So if we're to convert to a git master, it has to be > able to deal with back-patches. Given that the "same" patch is usually > textually a bit different from branch to branch, I'm not convinced that > git is going to make my life easier in that respect.
Yeah, I don't think it is. Nor do I think it will make it any harder. The main benefits I see as a committer are: - It's faster; - I can work off-line; - I can "queue up" patches in a branch and then drop them all into the master branch at once (assuming no conflicts, of course). This might be useful for security updates, among other things; and of course - I won't have to switch back and forth between two systems. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
