On Mon, May 3, 2010 at 16:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@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.
I doubt it will - not the way that we work (and I like the way that we
work with that). It might help a little in preparing them if they're
complex - but we seldom backpatch really complex patches.
I think we're more focused on making sure it doesn't make things
*worse* for that use-case.
-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/