Hacker News Reader

Comment by forgotpwd16 | Hacker News Reader

Lazy merge commits. The descriptions of the changes are in the commits from the merged branches.

This is why I always think emperor git wears no clothes. Hiding these kind of intermediate junk commits from history should not require rewriting and breaking the distributed history you all share. imho the correct solution would be a tag-like layer for annotating existing commits with metadata (additional signatures, hide-flags, retroactive comments, etc) or just a full 2nd dag, but whatever: git sucks at annotating history and annotating history is a core workflow in git.

The proper solution is that your merge commit should describe exactly what was merged and why. Git pre-fills it with a default "Merge branch-X into branch-Y" message so you can quickly exit the editor and still have a functioning DAG. It's just not ideal to leave it like that, precisely for this reason.

Fossil (https://fossil-scm.org/home/doc/trunk/www/index.wiki) doesn't fill out a default message, and sometimes that has annoyed me, but it does make you think about what you're doing. If you look in the Fossil and SQLite trees, almost all merges include a full description of what the merge was all about and why. Fossil also doesn't forget the entire history of the branch (including from which commit it was branched from), so it has that advantage too.

You might be interested in `git notes`. It does what it sounds like you are missing.

Almost like, mercurial had it figured out and got completely ignored because of the dominance of git's monoculture... The unit of work to be captured is the series (of commits), there's no issue having a linear history as long as series' boundaries can be identified. Merges can fit that bill, but doing it right and consistently with git is real work and consequently nobody does it.

Reply on news.ycombinator.com