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.
regards, tom lane