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 по дате отправления: