I was going to see if perhaps the abuse of Issues was what annoyed the maintainer more than the primary reason).
That's one of big downsides of a world where 99.99% of people create nothing (in terms of code or docs): when Github wasn't as popular many "consumers" didn't have accounts.
Now they do, and often tend to turn Issues into a discussion forum (which, contrary to Tobin's assessment, is a testament to the success of Github's UX, but not of the kind devs and power users want). The easiest way to deal with that is what Tobin did. Mirror the source to Github and lock (or ignore) GH issues.
Greatness isn't a requirement for acronyms, only long unwieldy titles. The cryptic string of letters being instantly recognizable among geeks, on the other hand...
You might be able to get the modal editing of Vim into other editors and IDEs, but you'll never get ability to modify your editor as if it's just another program (while it's running!), which is the main power of Emacs.
After working on a project that had code commit linters like this, that block you from committing if there's a violation, it's absolutely awful. You cannot work incrementally at all since "inject logger" is not a feature. Since most people aren't comfortable with rebasing (i don't know why), you end up with a ton of nonsense like a whole chain of refactors or feats that aren't actual refactors or features, they're just there to appease the tool since you can't commit (even locally!) without them.
Just stick to squash-before-merge-to-master, thanks.
Squash merge and commit linter only on master seems like the way to go here.
Then you can do whatever you want in your feature branch, and then when the feature is ready, create the squashed commit with the proper commit formatting.
squash merges to master are terrible for those that want to go looking why a certain change was introduced.
Now a larger change set is hidden behind a squash merge, and why was line 50 in foobar.py updated? Who knows, it was part of this giant merge request which no longer provides context why the developer changed line 50 in foobar.py.
Commit messages should explain why the change was made to the code. The amount of times that I go diving into a codebase only to find that the change was introduced in a larger commit that just says "fix bug" with no further information is maddening.
You're describing the wrong use of squash merges, and I agree they suck.
The right use is to allow me to make crappy, random commits on my own feature branch, clean them up those commits when I'm ready to release the change.
And the commit description will describe what's going on.
The key is that my feature branch is not long-lived - only a day or two, long enough for me to make a step forward before merging it back into mainline and then starting on the next step.
If you do this for short-lived feature branches only, why do you even need to squash merge for this? What I typically do for such things is to have a WIP commit that I amend and force push while working on the feature, then when everything is ready to merge I reset —-soft and make separate commits for each part of the work that can be compiled and tested indivually, rebase onto master and then fast-forward merge.
Even for a short lived feature branch that lasts maybe a day or so there may be a bug you find during testing that you quickly fix, or a change you make in existing code to help support the new feature or something you know is coming down the pipeline, and that information is now lost.
Or you could make consideration for tracking that change in source code a priority when making those changes and code appropriately.
The problem you describe is a problem because people are not prioritizing or valuing the commit history as a resource. If you fix that, then people will think about these things differently.
Squash and merge is not the only way to get things into master. You can rebase and squash commits as needed on your branch and then bring multiple commits from your branch onto master. That takes more advanced usage of git, but learning that makes sense once you start really valuing the history.
This was so bad at one point that I changed my git aliases to include '--no-verify'.
I like to push all my commits up so I can pull them back on a different machine or get early feedback. I'll typically rebase at the end with a proper commit message and explanation for each logical change.
I've been working on a project for months that uses this exact setup (commits are rejected if they are not formatted correctly) and the problem you describe just isn't that big of a deal. The benefits to the projects far outweigh the mild inconvenience.
I totally agree. I think the complaints are valid, but to be honest it seems petty. There are ways around it like you suggested. Having stuff like this really helps to solve process problems like not keeping a changelog up to date or incorrect version bumps, that can be a pain to manage across engineers. I think it’s important to consider that it helps the team as a whole.
Authentic culture isn't created by a microscopically small group of rich people. If you think that criticising an exploitative industry is the the same as turning people into cultureless robots, then you're missing the entire point.
What exactly makes a culture "authenic"? The funny thing is historically I can think of plenty of counter examples. Chokers caught on because of a high status woman wanting to cover up a neck scar. For better or worse that fundamentally is part of culture. Criticizing cultural practices is as well of course.
