Re: documentation for committing with git

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