On Mon, May 3, 2010 at 10:25 AM, 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.
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
