95 karma · joined August 25, 2019
In my opinion, if you say that a company unfairly avoids costs of regulations then it makes perfect sense to use them and transfer that saving to your own pocket. You're just confirming that you really believe it's an unfair market.
So, as much as you'd like to pretend it's just a matter of personal freedoms, bypassing housing codes via the guise of a tech company just enables negative externalities that restrict the personal freedoms of others. And the 'others' are the people who actually live there, making them more important than you.
If you are forced into using it to everything but still haven't taken the steps necessary for understanding it, why is that my problem?
Please don't ask me to give up features so you don't have to read the documentation. It is the most basic step of being a good citizen in a software ecosystem.
So write it.
I'm sorry to be so dismissive but it seems notable that those who like git get along with using it while those who complain about it just throw peanuts from the gallery. If it's obvious to you where git's flaws lie, it should be easy to write an alternative. If saner defaults and better discoverability are all you need, you don't even have to change the underlying structure, meaning you can just write a wrapper which will be found by all the competent developers whose productivity is so damaged that they do what they do when they encounter any problem and search the internet for a solution.
It seems notable this hasn't happened.
man git
The problem is people are unwilling to read the documentation. I have little patience for them demanding I change my workflow to accommodate their sloth.Fortunately, I don't have to worry because the overlap of 'people who don't RTFM' and 'people who are capable of articulating how they want to change git' have so far failed to write a wrapper that's capable of manipulating git trees without frustrating everyone else on the same repo.
And of course they can't: version control[1] is not a trivial problem. So I see no reason for us to demand that someone knows how to do it without studying when we don't expect the same for other auxiliary parts of software development such as build systems or containerisation or documentation.
[1] As opposed to the backup system the link wants to use it as: asking better questions is another important step. There's little reason to checkout an older commit as a developer unless you want to change the history, in which case it's important you understand how that will interact with other users of the same branch. If you don't need it to be distributed, you already have diff or cp or rsync or a multitude of other tools to accomplish effective backups.