On Tue, 20 Jul 2010 14:34:20 -0400 Robert Haas <robertmh...@gmail.com> 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. Here's a few responses from the point of view of somebody who has been working with git in the kernel community for some years now. Hopefully it's helpful... > 1. Inability to cleanly and easily (and programatically) identify who > committed what. No, git tracks committer information separately, and it's easily accessible. Dig into the grungy details of git-log and you'll see that you can get out just about anything you need, in any format. IMHO, vandalizing the author field would be a mistake; it's your best way of tracking where the patch came from and for ensuring credit in your changelogs. Why throw away information? > 2. Branch and tag management. In CVS, there are branches and tags in > only one place: on the server. In git, you can have local branches > and tags and remote branches and tags, and you can pull and push tags > between servers. If I'm working on a git repository that has branches > master, REL9_0_STABLE .. REL7_4_STABLE, inner_join_removal, > numeric_2b, and temprelnames, I want to make sure that I don't > accidentally push the last three of those to the authoritative > server... but I do want to push all the others. Similarly I want to > push only the corrects subset of tags (though that should be less of > an issue, at least for me, as I don't usually create local tags). I'm > not sure how to set this up, though. Branch push policy can be tweaked in your local config. I'm less sure about tags. It's worth noting that the kernel community does very little with push in general - things are much more often pulled. That may not be a workflow that's suitable for postgresql, though. > 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? That seems like a terrible idea to me - why would you destroy history? Obviously I've missed a discussion here. But, the first time somebody wants to use bisect to pinpoint a regression-causing patch, you'll wish you had that information there. > 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? A good general rule of thumb is to treat publicly-exposed history as immutable. As soon as you start rebasing trees you create misery for anybody working with those trees. If you're really set on avoiding things like merges, there are ways to set up scripts on the server to enforce policies. jon -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
