Re: antisocial things you can do in git (but not CVS)

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: antisocial things you can do in git (but not CVS)
Дата
Msg-id 4C4623CD.6080904@dunslane.net
обсуждение исходный текст
Ответ на antisocial things you can do in git (but not CVS)  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Christensen
Дата:
Сообщение: Re: Patch for 9.1: initdb -C option
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Patch for 9.1: initdb -C option