[jes5199]

no-ff is useful when you need to revert the whole merge - the merge commit delimits the boundaries of what used to be a separate branch. If you fast-forward, then you have to use your human brain to figure out how many commits to revert and when you're reacting to "augh I just broke master by adding these 12 commits" you might make a mistake.

[nsfyn55]

Yeah that's why you squash your 12 commits into a single commit that represents the deliverable.

This is my point I find the 12 commits to be unnecessary. I've never been burned by squashing. The only arguments I've heard against it are ideological(you're destroying history, etc.)

[jes5199]

oh! Well, I like reading many little diffs more than I like reading a few big diffs, but the distinction is purely aesthetic. A team should try to agree on an aesthetic, but otherwise, ::shrug::.

[nsfyn55]

Its not exactly aesthetic. Little diffs and big diffs are not isomorphic. They could conflict with eachother. The only true diff is either diffing a squashed commit or diffing over the whole range. And if you are diffing over a range all the time you might as well be squashing and rebasing so you get the benefits of linear history.

This is my primary complaint regarding rebasing and no-ff. It leaves all these useless and confusing commits around. A lot of times the content of the commit was undone by a commit in the family. Its usually not useful to anyone and can only be reasoned about by the original author. When you merge all that crap lands in `master`

Interestingly I think I am actually learning something during this thread. The hardcore `no-ff` actually misunderstands rebase. They find the billion crap commits to be disruptive as well and want the merge commit so they can get rid of that mess. But I just say the mess is unnecessary. Just squash and you get the best of all worlds. You'll never miss those 12 commits