This is a lot to address but please consider all of the facts.
There are hooks for pulling and whatnot. This is a vector for malicious code execution.
Not everyone has a GUI system (window system).
Git _has_ to be able to expose low level commands while still being usable.
Decentralization is a _good thing_ when it comes to git. It is directly one of the goals of open source software, for which Git was built.
You can configure all of these things for your team provided they run an init command at least once. Then set up your system however you like via hooks that automatically run to update their configs as necessary.
Remember, your development process is not my development process. Also, not every system that clones a repository wants to run hooks. Git shouldn't force them to.
You can 100% enforce line endings, please research. You just have to configure it in the unit command as mentioned above.
If your team members are not adhering to your policies, then you're not managing them well. It's not git's problem to do your job for you.
For those of us who use git on a daily basis across a wide range of environments, repositories, usecases and websites, git is a dream to use.
This line of thinking is low effort and pointless. There's no hate here (in fact, I said love). Tools are meant to be helpful and talking about how to improve them is always good.
Git has lots of configs that are automatic and shared and that you can locally override yourself such as the ignore and attribute files. Why not more? I have no issue (and in fact prefer) if clients can override the projects configuration but git should support a turnkey workflow, at least for its own features. As it stands, you can't add submodules seamlessly, for example.
Its not about adherence. Workflow as Simon-Says is just a bad workflow. This stuff should take zero cognitive load.
This is true. But the number of devs who work entirely in shell is dwindling as basically everything transitions to IDEs.
> If your team members are not adhering to your policies, then you're not managing them well. It's not git's problem to do your job for you.
I totally disagree. There is a reason why we use linters to enforce style guides. Tooling and automation always helps, even if you have strong engineers who are trying to do the right thing.
> If your team members are not adhering to your policies, then you're not managing them well. It's not git's problem to do your job for you.
Well it could help you in that, and we know that because other VCSes do. Have you managed a large inexperienced team with an offshore component? You are herding cats and there is never enough time to look at everything.
> Have you managed a large inexperienced team with an offshore component?
Yep! The engineers we had worked fine like this with just Git, github issues and slack at the time. I've left the company but I know that slack didn't suit them well so they switched to something else.
There are hooks for pulling and whatnot. This is a vector for malicious code execution.
Not everyone has a GUI system (window system).
Git _has_ to be able to expose low level commands while still being usable.
Decentralization is a _good thing_ when it comes to git. It is directly one of the goals of open source software, for which Git was built.
You can configure all of these things for your team provided they run an init command at least once. Then set up your system however you like via hooks that automatically run to update their configs as necessary.
Remember, your development process is not my development process. Also, not every system that clones a repository wants to run hooks. Git shouldn't force them to.
You can 100% enforce line endings, please research. You just have to configure it in the unit command as mentioned above.
If your team members are not adhering to your policies, then you're not managing them well. It's not git's problem to do your job for you.
For those of us who use git on a daily basis across a wide range of environments, repositories, usecases and websites, git is a dream to use.
Really tired of the "git hate".