[nsfyn55]

I have had this ideological debate about "fast forwarding" more times that I can count. I agree with the author "no-ff" is silly. I've been working on professional software teams for over a decade. When I encountered fast forwarding/rebasing it was absolutely a breath of fresh air. I've been using git now for 5 years and I have not encountered a single instance where using either of these tools has presented any sort of problem. I can't remember a week where having a concise, readable history hasn't proven its value. I also can't remember a single time I've said "Man I'm glad I had all these merge commits around they really saved my proverbial bacon"

From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. It gives them something to do between harping on whether your behavior is in the correct "domain", deciding if a list comprehensions are truly "pythonic", and spending that extra month perfecting the event sourcing engine to revolutionize the "contact us" section of your site.

[JanezStupar]

Because you do not need something, then it has to be useless.

> From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. Incredible irony.

[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

[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