[nsfyn55]

well can you provide the killer use case that none of us can live without?

I mean its certainly possible that in some tiny fraction of cases I might say "man I could fix this a lot easier if I had the merge commit" its just in the 10,000's of examples that form my experience I haven't stepped on that particularly landmine yet.

Even with that said, my development philosophy compels me to choose "Simplicity over Completeness" and is utilitarian to the core. I will chose whatever is most effective in the vast majority of cases.

Some folks look at "Source Control History" as some pristine, historical record of how things went down. Since I am not an accountant or auditor this has little value to me. It encumbers the day to day to optimize for a case that is almost certain to never happen. A first-order approximation of the history that optimizes for the day-to-day needs of an organization is far more suitable in almost every case.

I use the term "local team pedant" its not a bad thing. Some folks just have a need for things to be "complete" and feel compelled to do so for irrational(usually expensive) reasons. In my own experience the person that is the "no rebase/ never fast forward" cheerleader can never give a solid objective answer as to what the benefit is. Its usually always something like what this no-ff-er suggests(http://walkingthestack.blogspot.com/2012/05/why-you-should-u...) . Things like "I can see whats on a branch, etc." That in itself is not a justification. Its just words. If you could someone how demonstrate how this reduces development costs or offers a better way to organize work and is simultaneously better than the more idiomatic alternatives then I'm all for it.

[JanezStupar]

The killer use case for me is getting to figure out how and when something happened.

Also merging two branches that tend to touch upon same modules but are not kept in sync all the time (due to whatever reasons) is a lot simpler when you use --no-ff.

You say that these properties are bullshit, but I found them invaluable when fixing bugs and architectural defects and where it was important to find out when and how the bug or a behaviour occurred. And funny that you mention accountants and auditors. Because being able to do forensics more easily on the codebases that I worked on has saved me and my clients many hours and gray hair. And I have found myself in situations where

I can live without --no-ff, I can live without git even. There is plenty of people out there not using any kind of source control and they are living just fine.

Your last paragraph is a nice example of psychological projection. If you weren't so narrow minded you could have used your energy to learn something.

Myself I use --no-ff because it fits the kind of work I do very well. I haven't lost a minute of sleep or time over its deficiencies. And I am pretty certain that I spend a whole lot less time fiddling with git than people who advocate "agressive rebasing".

I do admit you have some merit in pointing out how bad a git history looks when littered with merge commits for single commit branches. But then, this is pretty easy to fix. Just use a fucking vanilla merge, or indeed a rebase when it fits the problem. Another way to work around the bad aspects of --no-ff approach is by using a better git history explorer.

[nsfyn55]

I never said it was bullshit. I'm just looking for your "falsfiability" criteria. My point is "no-ff" is cluttery and no one can tell me in "objective terms"(e.g. newtons, projects/year) backed by clear evidence that there is any benefit. All I see is downside. Your points are pretty shakey lets break them down shall we?

> Your last paragraph is a nice example of psychological projection. If you weren't so narrow minded you could have used your energy to learn something.

well thats clearly ad hominem nonsense. So nothing to see there.

>Myself I use --no-ff because it fits the kind of work I do very well. I haven't lost a minute of sleep or time over its deficiencies. And I am pretty certain that I spend a whole lot less time fiddling with git than people who advocate "agressive rebasing".

No point to any of that either.

>Also merging two branches that tend to touch upon same modules but are not kept in sync all the time (due to whatever reasons) is a lot simpler when you use --no-ff.

This might have some merit. But I don't really understand what you mean.

>You say that these properties are bullshit, but I found them invaluable when fixing bugs and architectural defects and where it was important to find out when and how the bug or a behaviour occurred. And funny that you mention accountants and auditors. Because being able to do forensics more easily on the codebases that I worked on has saved me and my clients many hours and gray hair. And I have found myself in situations where

Here you actually makes some points but they are all anecdotal. How many hours has it saved you? How could you even know this unless you split time into two parallel experiments and measured them independently? Its not that there is anything wrong with relaying an anecdote. But when you introduce this handwaving nonsense as justification for something as though it has the same strength as an objective measurement that I call bullshit.

>I do admit you have some merit in pointing out how bad a git history looks when littered with merge commits for single commit branches. But then, this is pretty easy to fix. Just use a fucking vanilla merge, or indeed a rebase when it fits the problem. Another way to work around the bad aspects of --no-ff approach is by using a better git history explorer.

After all those words here you start to make some sense. Of course I would use `no-ff` if I saw some value in a "merge commit" which is the mirror to your point. But my point is just that ... I've never encountered that case or had it concisely explained to me