Jonathan Corbet wrote:
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?
That seems like a terrible idea to me - why would you destroy history?
Obviously I've missed a discussion here. But, the first time somebody
wants to use bisect to pinpoint a regression-causing patch, you'll wish you
had that information there.
We have a clear idea of what should be part of the public history
contained in the authoritative repo and what should be history that is
private to the developer/tester/committer. We don't want to pollute the
former with the latter. The level of granularity of our current CVS
commits seems to us to be about right.
So when a committer pushes a patch it should add one fast-forward commit
to the tree. We want to be able to bisect between these commit objects,
but not between all the work product commits that led up to them. Of
course, developers, committers and testers can keep what they like
privately - we're only talking about what should go in the authoritative
repo.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
