5 ms·
Peter notes in the LWN comments that committers use merging in their personal repos regularly. The restriction only applies to commits to the master. Many peopl
by selenamarie 16y ago
Peter notes in the LWN comments that committers use merging in their personal repos regularly. The restriction only applies to commits to the master. Many people share their individual repos and branches to git.postgresql.org (and GitHub).
The point is to keep our commit history clean while we figure out best practices for the project.
- Groxx 16y agoI've been wondering what the point of keeping a "clean" history is. In what way is less information better? All this means is you're destroying the real history, rewriting it to look more like a straight line, which is not at all how it was developed. If you want such a history to reflect how it was developed, there are wonderful version control programs out there. Like RCS. Why not just use that?
- silentbicycle 16y agoWhile I can't speak for the parent comment, one reason people try to keep clean commit histories in git is that you can easily undo, cherry pick, etc. individual commits. If all of the changes necessary to add a feature / fix a major bug are in one commit, backporting that commit becomes much easier. If those changes are broken up in multiple commits ("fix this issue" + "oops, forgot that file (and unrelated changes in the same file)"), then it's more trouble. It usually doesn't make sense to have the repository in those intermediate states anyway, once the primary commit is done. History rewriting can make those commits atomic. Generally speaking, "clean" git histories have relevant history combined, but no significant information lost.
- chousuke 16y agoI don't think there's any reason you couldn't have both merges and a clean history. 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.
- silentbicycle 16y agoIndeed. 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.
- selenamarie 16y agoThis is definitely true of Postgres, where backporting is relatively common (currently to 5 versions). Another cultural difference is that the narrative in our commit log has a pretty strong voice. That consistency is valued above individual details about exactly who did what to produce the patch. If you want the details, we have extensive discussions of what lead to a patch on the pgsql-hackers mailing list. Our archives and threads are pretty well organized. We commonly refer back to threads 3-4 years old when discussing design decisions. I agree with many of the commenters that it would be nice to have all of the details that lead up to the final patch. Maybe something like a sub-commit history that is generally hidden, but possible to mine when desired. Here my ignorance of git is showing, as I don't know exactly what is possible.
- grammaton 16y agoAlso keep in mind that a common work flow for tracking down an issue is to revert back to previous versions until you narrow down which one introduced the bug. In that case, you most certainly want fewer, cleaner commits. Narrowing a bug down to a commit that introduced four new features, fixed six bugs, and cleaned up a couple of dozen oopsies in the code base doesn't help you much.