As I'm (nearly done) writing a book about mm to learn mm deeply, I totally buy the 'write about it to understand' thing, as I've experienced it first hand, endlessly.
@ljs@liskin it's certainly debatable, but it does simplify life in the sense that people don't have to worry about cleaning up their commits, which in my experience can get tedious.
@6d03@liskin yeah this is the 'argument', maybe I'll be less zen and tell you it's just terrible. It's not debatable, it's terrible.
Why are you even using source control?
You end up with a 10,000 line commit? No bisect now, no ability to back port, no description of the logic behind things, no separation of moving code/changing it.
I've seen somebody do a 5,000 line move of code and subtle changes in it - good luck dealing with that as one commit.
You remove all code-specific context, all things that are sub-PR level.
All for what purpose? To make life a little easier or neater?
If people can't be bothered to rebase properly, then why on earth do you think they'd put every bit of detail needed in a PR description?
It's impossible to argue these things anyway, and pointless, because those making the decisions are not the ones dealing with the consequences of this.
I've literally run into every single one of these issues in practice.
And you're commenting on a post where I literally point out the benefit of a high-granularity comment that wouldn't exist in this scheme?
@6d03@liskin to be clear I"m not attacking you at all :) just have strong feelings on this issue. I'm just attacking the auto-squash concept as an idea.
I agree, having all the relevant information in commit messages would be ideal. But what do you do when your project already has its established workflows?
Add comment