On 21/07/10 18:22, Robert Haas wrote:
> At the developer meeting, I promised to do the work of documenting how
> committers should use git. So here's a first version.
>
> http://wiki.postgresql.org/wiki/Committing_with_Git
>
> Note that while anyone is welcome to comment, I mostly care about
> whether the document is adequate for our existing committers, rather
> than whether someone who is not a committer thinks we should manage
> the project differently... that might be an interesting discussion,
> but we're theoretically making this switch in about a month, and
> getting agreement on changing our current workflow will take about a
> decade, so there is not time now to do the latter before we do the
> former. So I would ask everyone to consider postponing those
> discussions until after we've made the switch and ironed out the
> kinks. On the other hand, if you have technical corrections, or if
> you have suggestions on how to do the same things better (rather than
> suggestions on what to do differently), that would be greatly
> appreciated.
I'm a bit disappointed that the wiki page advises against
git-new-workdir - that's exactly what I was planning to use. It claims
there's data loss issues with that, does someone know the details? Is
there really a risk of data loss if multiple workdirs are used, in our
situation?
I'm planning to have only one local repository, with one workdir per
branch. When applying a patch to multiple branches, I could work
simultaneously on all branches, finish and commit the patches on all
branches, and finally do one "git push" to push all the changes to the
PostgreSQL repository in one go.
I'm working like that with the internal EDB repository right now, and
seems to work fine. I keep the master branch checked out in the "main"
workdir, within the repository, and for each backbranch there's an extra
workdir created with git-new-workdir. Though I've only been doing this
for a month or so - if there's issues I might not have noticed yet.
PS. I highly recommend always using "git push --dry-run" before the real
thing, to make sure you're not doing anything funny.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com