Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4]
If enough of the following apply strongly enough to your project:
* Very small codebase
* A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review
* Not doing anything technically challenging
* You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature
then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane.
I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6]
> Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop
I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook.
Again, in my experience, that isn't it. It's like NASA's rules. People who write garbage commit messages and have a chaotic and unconsidered version control workflow, generally lack the skill to do otherwise. As they lack version control skills, they haven't had the opportunity to internalise the benefits. Those with the skill to make disciplined use of version control tend to do so on every project, as the effort required is modest and is repaid even on minor projects.
We're talking about low-hanging fruit here. It's not like adopting the MISRA C programming style, which really does severely restrict the programmer.
Sloppy use of version control doesn't make you more effective. It just doesn't work that way.
Torvalds himself writes up proper commit messages even for his toy projects. [0][1] I really doubt it takes him much time or effort. You really think he's not pragmatic?
If enough of the following apply strongly enough to your project:
* Very small codebase
* A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review
* Not doing anything technically challenging
* You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature
then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane.
I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6]
> Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop
I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook.
[0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=log
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
[2] https://git.ffmpeg.org/gitweb/ffmpeg.git/log
[3] https://github.com/openjdk/jdk/commits/master/src/hotspot
[4] https://github.com/openssl/openssl/commits/master/
[5] https://spinroot.com/gerard/pdf/P10.pdf The Power of Ten - Rules for Developing Safety Critical Code
[6] https://tigerstyle.dev/