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

On Tue, Jul 20, 2010 at 20:34, Robert Haas <robertmhaas@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.  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.  With CVS, the author of a revision is the person who
> committed it, period.  With git, the author string can be set to
> anything the person typing 'git commit' feels like.  I think there is
> also a committer field, but that doesn't always appear and I'm not
> clear on how it works.  Also, the author field defaults to something
> dumb if you don't explicitly set it to a value.  So I'm worried we
> could end up with stuff like this in the repository:

I'm pretty sure we can enforce this on the server side, refusing
commits that don't follow our standard. I haven't done it myself
(yet), but I've read about it.


> My preference would be to stick to a style where we identify the
> committer using the author tag and note the patch author, reviewers,
> whether the committer made changes, etc. in the commit message.  A
> single author field doesn't feel like enough for our workflow, and
> having a mix of authors and committers in the author field seems like
> a mess.

+1.


> 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.

We could put a safeguard in place on the server that won't let you
push a branch and require that additions of new branches be done
manually on the server?


> 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, I haven't done it, but I've read about it, and I'm almost
certain we can enforce this, yes.


> 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?

That's something we need a good policy for. Merge commits are special.
For content commits, I think we should basically *never* do that. If
someone commits bad content, we should just make a revert commit which
keeps history linear and just removes the changes as a new commit.


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/