[reificator]

My response:

You've never looked at a piece of code that you wanted to see the history of?

You've never needed to revert a single change a few hours/days/weeks later?

You've never needed to track down the person who wrote a piece of code in order to ask them for clarification?

You've never needed to see the original change reason for a line of code that is doing some weird, specific thing that seems out of place?

You've never needed to have two people edit the same file at the same time?

[crististm]

I've got these responses on a similar question: "we don't need to see the commit logs so who cares about them or the history being pretty and clear? Nobody is looking at the history!"!!

The question was "Let's submit pull requests as a clean job not as a homework draft. Why don't we allow push force on work branches so that we can squash fixup commits after review?"

Blows my mind that those are senior developers that are otherwise seemingly competent at what they do. There is some pinch of job security there though.

[bmarkovic]

There are valid reasons for a "never rewrite history" policy, but their validity pales further you go from the master branch.

The thing is that in a lot of scenarios people need to do huge chunks of work in feature branches. Sometimes a 3000 line "refactor the world" squashed commit is really unhelpful. The best policy is always well thought of weighted case-by-case decisions.

However, on projects with a lot of hands on the keyboard such policy is unrealistic and someone will do the opposite of what they should and wont ask or discuss. People, especially in our business, hide incompetence behind aloofness and silence.

So in that case, with a lot of people that are hard to manage, stiff policy is the best choice and there probably are reasons why people want to preserve history, no matter how hairy it looks, at least it's there and you can find stuff in it.

[crististm]

I bet they are willfully blind to that difference.