I'm not entirely sure we need a new VCS to achieve most of this. A lot of it can be done through guidelines and a good UI (which could be either a GUI or a CLI) on top of git. For me git is pretty easy and simple : I use it through Jetbrain's IDE 90% of the time and I chose to completely ignore rebasing and encourage my team not to use it : our commit history doesn't look clean and so what ? At least it shows what actually happened.
For the same reason I'm divided regarding S
Squashing on PRs : On the one hand it does make it things cleaner and prevent commit messages that are hard to understand out of context, but on the other hand you lose the justification for a specific change. Sometimes I don't care that you changed a variable name 2 years ago to make it more consistent, I just want to know what feature that part of the code relates to... And sometimes I do want to know why that variable name was changed.
I think what I'd really like is a way to keep all the commit, but bundle them together with a message that explains the whole feature. I mean that's what PRs are for, but as far as I know you can't really see the PR from git once it's been merged since they're handled by your repository and not in git itself... So I guess that's the thing I'd like to see added in a got successor : a way to keep both individual commits and merged PRs.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
JetBrains git integration is amazing, I have an article planned on this.
Squashing on GitHub works exactly like you say. If you look at the main branch, it's only one commit, but if you need the details, you click on the link to the PR and you can see what happened step by step.
I'm not entirely sure we need a new VCS to achieve most of this. A lot of it can be done through guidelines and a good UI (which could be either a GUI or a CLI) on top of git.
I agree, the issue is that there is a strong culture in the git community that goes against that, that discourage people to use git clients, that pushes "best practices" that reflect what they think is the one true way to use git, ...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not entirely sure we need a new VCS to achieve most of this. A lot of it can be done through guidelines and a good UI (which could be either a GUI or a CLI) on top of git. For me git is pretty easy and simple : I use it through Jetbrain's IDE 90% of the time and I chose to completely ignore rebasing and encourage my team not to use it : our commit history doesn't look clean and so what ? At least it shows what actually happened.
For the same reason I'm divided regarding S
Squashing on PRs : On the one hand it does make it things cleaner and prevent commit messages that are hard to understand out of context, but on the other hand you lose the justification for a specific change. Sometimes I don't care that you changed a variable name 2 years ago to make it more consistent, I just want to know what feature that part of the code relates to... And sometimes I do want to know why that variable name was changed.
I think what I'd really like is a way to keep all the commit, but bundle them together with a message that explains the whole feature. I mean that's what PRs are for, but as far as I know you can't really see the PR from git once it's been merged since they're handled by your repository and not in git itself... So I guess that's the thing I'd like to see added in a got successor : a way to keep both individual commits and merged PRs.
JetBrains git integration is amazing, I have an article planned on this.
Squashing on GitHub works exactly like you say. If you look at the main branch, it's only one commit, but if you need the details, you click on the link to the PR and you can see what happened step by step.
I agree, the issue is that there is a strong culture in the git community that goes against that, that discourage people to use git clients, that pushes "best practices" that reflect what they think is the one true way to use git, ...