Re: antisocial things you can do in git (but not CVS) - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: antisocial things you can do in git (but not CVS)
Date
Msg-id 4C4623CD.6080904@dunslane.net
Whole thread Raw
In response to antisocial things you can do in git (but not CVS)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers

Robert Haas wrote:
> I have some concerns related to the upcoming conversion to git and how
> we're going to avoid having things get messy as people start using the
> new repository.  git has a lot more flexibility and power than CVS,
> and I'm worried that it would be easy, even accidentally, to screw up
> our history.
>
> 1. Inability to cleanly and easily (and programatically) identify who
> committed what.  
>   

Each committer sets their name and email using git config. Doesn't look 
like a problem. We don't have such a large number of committers that 
this should be much of an issue. Maybe we can set a pre-receive hook to 
make sure that it's set appropriately?

> 2. Branch and tag management.  
>   
[snip]

I'm inclined to say that as now committers should not normally push 
tags. Marc or whoever is managing things should create the various tags. 
I think our current tagging policy is about right. "git push" doesn't 
push tags by default, so you'd have to be trying hard to mess this up.
> 3. Merge commits.  I believe that we have consensus that commits
> should always be done as a "squash", so that the history of all of our
> branches is linear.  But it seems to me that someone could
> accidentally push a merge commit, either because they forgot to squash
> locally, or because of a conflict between their local git repo's
> master branch and origin/master.  Can we forbid this?
>   

Again, a pre-receive hook might be able to handle this. See 
<http://progit.org/book/ch7-4.html>
> 4. History rewriting.  Under what circumstances, if any, are we OK
> with rebasing the master?  For example, if we decide not to have merge
> commits, and somebody does a merge commit anyway, are we going to
> rebase to get rid of it?
>
>   

In the end, if we screw up badly enough we can just roll things back. It 
would be a pain, but not insurmountably so. I think we need to expect 
that there will be some teething issues. I keep 7 days worth of backups 
of the CVS repo constantly now, and I'll probably do the same with git, 
and I'm sure there will be other backups.

cheers

andrew


pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: Patch for 9.1: initdb -C option
Next
From: "Kevin Grittner"
Date:
Subject: Re: Patch for 9.1: initdb -C option