From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Aidan Van Dyk <aidan(at)highrise(dot)ca>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Alexey Klyukin <alexk(at)commandprompt(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "cedric(dot)villemain(dot)debian" <cedric(dot)villemain(dot)debian(at)gmail(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: missing file in git repo |
Date: | 2010-05-03 14:25:51 |
Message-ID: | 15211.1272896751@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-05-03 14:31:01 | Re: missing file in git repo |
Previous Message | Magnus Hagander | 2010-05-03 14:22:53 | Re: missing file in git repo |