Re:Lessons from PostgreSQL's Git transition
by silentbicycle on Tuesday October 19, 2010 @09:44AM
(#1807060)
Indeed. I don't understand the problem the postgres people had with merge. I'm sure they have their reasons, though.
When people talk about clean commit histories in git, they usually mean rebasing / merging topic branches atomically like we said, though, and Groxx's comment asked about the rationale.
IIRC the git project itself accomplishes this so that the maintainer forms topic branches from patch series sent to the mailing list (a single patch must still be a self-contained change, so "cleanliness" and bisectability is retained) and then merges those topic branches to whatever branch they're approved for: pu for "proposed updates", "next" for the next "major" release, and "master" for the stable branch. The system is interesting in that "pu" gets completely rebased regularly while next and master have immutable history; and master is periodically merged with next, so that any fixes for the stable branch get propagated into next as well.