3 ms·

I don't want to victim blame too much, but this line stood out to me > There's no "body" to this commit. It's just a "Merge:" and two other commits Commits ar

by zokier 3y ago

I don't want to victim blame too much, but this line stood out to me > There's no "body" to this commit. It's just a "Merge:" and two other commits Commits are snapshots of repository state, and merges "obviously" have differences from its parents. So not having "body" for a commit is bit nonsensical in git (yes, technically you can make empty commits but that's a special case). These sort of things are where having good mental model of git is useful. As I have my share of hairy merges, it is pretty intuitive that merge commits can, and in many cases need to, have changes that are not part of either parent. Maybe something like pijul (/darcs) would handle things differently here, but I believe that merges are fundamentally difficult problem.

planede 3y ago
Merges of course should have changes, but IMO they shouldn't have changes that are not resolving conflicts (either actual conflicts marked by git, or conflicts that manifest in failing tests, etc...). An entirely unrelated change stuffed into a merge commit is inappropriate.
thriftwy 3y ago
That's why reasonable projects limit their usage to the smallest reasonable scope, and use rebase/squash. You don't have to adopt a hard problem. It actually escapes me why Linus decided to make git a merge-first VCS in the first place. There aren't many projects which are more linear in nature than Linux kernel.
nebulous1 3y ago
Merging a branch is one of the "special cases" where an empty merge commit can be used. Git will use fast forward by default but if you want to preserve the history as a separate branch you can use an empty merge commit instead.
tsimionescu 3y ago
> So not having "body" for a commit is bit nonsensical in git (yes, technically you can make empty commits but that's a special case). These sort of things are where having good mental model of git is useful. This isn't a problem with the author or her mental model, it is a problem with `git log -p`. The output she is describing is exactly how merge commits show up there, with no other flags.

by zokier 3y ago

planede 3y ago

Merges of course should have changes, but IMO they shouldn't have changes that are not resolving conflicts (either actual conflicts marked by git, or conflicts that manifest in failing tests, etc...). An entirely unrelated change stuffed into a merge commit is inappropriate.

thriftwy 3y ago

That's why reasonable projects limit their usage to the smallest reasonable scope, and use rebase/squash. You don't have to adopt a hard problem. It actually escapes me why Linus decided to make git a merge-first VCS in the first place. There aren't many projects which are more linear in nature than Linux kernel.

nebulous1 3y ago

Merging a branch is one of the "special cases" where an empty merge commit can be used. Git will use fast forward by default but if you want to preserve the history as a separate branch you can use an empty merge commit instead.

tsimionescu 3y ago

> So not having "body" for a commit is bit nonsensical in git (yes, technically you can make empty commits but that's a special case). These sort of things are where having good mental model of git is useful. This isn't a problem with the author or her mental model, it is a problem with `git log -p`. The output she is describing is exactly how merge commits show up there, with no other flags.