@yoz-y: I did read the post, thanks very much. It took no time at all to search (`/\(delete\|remove\)`) those alternatives on the man pages, hence suspected lac

@yoz-y: I did read the post, thanks very much. It took no time at all to search (`/\(delete\|remove\)`) those alternatives on the man pages, hence suspected lack of RTFM. :) My point was a lot of these 'quirks' have been aligned over time. For example, your `git push origin :branchName` can also be expressed `git push -d origin branchName`. There is an obvious convergence toward using the `remove` command in command sub-groups, likewise using a `[-d|--delete]` flag in cases where commands are singular actions. Your point about versioning is a good one. Default behaviours have been updated using a config flag and a warning in the past, perhaps something similar could be done. I think we're in agreement that Git's porcelain interface could do with a good deal of refurbishment. However, Git's backwards compatibility has become a prison, given you have a ton of code out in the wild running on the promise of: "Any `git` is good `git`". This is where a lot of the cruft lies. IMO part of the responsibility lies with the community who are creating learning resources to keep up with the changes made - especially those monetising. So newcomers learn a sane, modern, consistent interface, instead of a bunch of esoteric legacy incantations. Indeed, these resources too rely on Git's promise of backwards compatibility to maintain their level of complacency. Having said that, there's no reason some individual(s) who feel(s) strongly could't write a 'training potty' level interface as a separate binary; intended to be user-friendly, OCD consistent, and to be understood as a functional but completely non-conceptual black box. But they haven't.