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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: antisocial things you can do in git (but not CVS)
Date: 2010-07-20 19:12:29
Message-ID: 1279653149.2841.27.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On tis, 2010-07-20 at 14:34 -0400, Robert Haas wrote:
> Right now, it's easy to find all the commits by a particular
> committer, and it's easy to see who committed a particular patch, and
> the number of distinct committers is pretty small. I'd hate to give
> that up.
>
> git log | grep '^Author' | sort | uniq -c | sort -n | less

git log --format=full | grep '^Commit' | sort | uniq -c | sort -n | less

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

Well, I had looked forward to actually putting the real author into the
author field.

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

I'm going to use one separate clone for my development and one
"pristine" one for the final commits and copy the patches over manually.
That also solves the next problem ...

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-07-20 19:13:45 Finding slave WAL application time delay
Previous Message Alvaro Herrera 2010-07-20 19:05:11 Re: dynamically allocating chunks from shared memory