* Robert Haas: > 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.
It's even more difficult than that. Git does not record at all who updated a particular branch to include a specific commit. This operation does not leave any metadata behind. It is possible to write a log file for audit purposes, but it's an out-of-band solution. > 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. It would be possible to enforce that on the server side, but it would interfere with merges. > 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? It's possible to do this with some scripting on the server side. -- Florian Weimer <fwei...@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers