These new commands make a lot more sense, but the weird thing is they don’t bring anything else to the table.
They behave exactly like the existing ones, so much that anyone that really cared could have just aliased them.
So is there any incentive to switch for the people who went through the trauma of burning the old ones in their soul ? (I often heard that knowing how it works internally makes git commands feel natural. I was lied to)
They don't behave exactly like the old ones, because they do less - which means it's harder to accidentally do the wrong thing, and it's easier to guess what its arguments do.
If you know the old ones already and don't make mistakes, it's fine not to use these, really. I consciously got the new commands into my muscle memory in case I'm pair programming or someone less familiar with Git is looking along.
And yeah, knowing how Git works makes it a lot easier to understand, but it doesn't make the commands more natural. (Except perhaps knowing when you can use a commit id instead of a branch name.)
I had git-checkout syntax burned into my soul. I switched to switch/restore a year or so ago and am happy to be mostly unburdened of git-checkout. I say mostly because I still use it in scripts so they work with old git versions.
So is there any incentive to switch for the people who went through the trauma of burning the old ones in their soul ? (I often heard that knowing how it works internally makes git commands feel natural. I was lied to)