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
> 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