* 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 <fweimer@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