At 2010-07-20 14:34:20 -0400, robertmh...@gmail.com wrote: > > I think there is also a committer field, but that doesn't always > appear and I'm not clear on how it works.
There is always a committer field, and it is set sensibly as long as the committer has user.name and user.email set correctly with git-config. It is not displayed by git-log by default, unless it is different from the "author". (As PeterE showed, it's easy to get the list of committers.) > 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. An aside: as a patch author (and elsewhere, as a committer), it's nice when the log shows the author rather than the committer. Will we really have so many patches with multiple authors or other complications that we can't set the author by default and fall back to explanations in the commit message (e.g. "applied with changes") for more complicated cases? > I want to make sure that I don't accidentally push the last three of > those to the authoritative server... By default (at least with a recent git), "git push" will push branches that are tracking remote branches, but new local branches have to be pushed explicitly to create them on the remote. So don't worry about that. > 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. I admit I haven't been paying as much attention as I should, but I did not know there was such a consensus. If anyone could explain the rationale, I would be grateful. > But it seems to me that someone could > accidentally push a merge commit […] > Can we forbid this? Yes, I suppose it's possible, but personally I think it would be a waste of time to try to ban merge commits. > 4. History rewriting. Under what circumstances, if any, are we OK > with rebasing the master? Please, let's never do that. The cure for pulling a rebased branch into an existing clone may seem simple, but it's a huge pain in practice, and it's never really worth it. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
