3 ms·

I'm surprised you get tripped up by `git rm`. How do you remove a file from your FS usually? In the case of `git remote`, `git remote remove` and `git remote r

by rounce 10y ago

I'm surprised you get tripped up by `git rm`. How do you remove a file from your FS usually? In the case of `git remote`, `git remote remove` and `git remote rm` are synonymous. It's all on the man page.

yoz-y 10y ago
The parent definitely did read the manpage if you read the post. The problem with git is that it has a different vocabulary for the same action (e.g.: remove) for different entities. (git push origin :branchName anyone?) By not breaking the compatibility the git interface accumulates cruft over time. I think they would gain by versioning the cli interface somehow and just removing old commands that were since replaced by better alternatives.
- nindalf 10y ago
  Something must be wrong with me because I almost never remember the command to do that. Perhaps its because I only do it once in 2 months or so. Thankfully my browser has me covered. I type in "git delete" and it autocompletes to links describing deletion of branches and tags.
rounce 10y ago
@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.

by rounce 10y ago

yoz-y 10y ago

The parent definitely did read the manpage if you read the post. The problem with git is that it has a different vocabulary for the same action (e.g.: remove) for different entities. (git push origin :branchName anyone?) By not breaking the compatibility the git interface accumulates cruft over time. I think they would gain by versioning the cli interface somehow and just removing old commands that were since replaced by better alternatives.

nindalf 10y ago
Something must be wrong with me because I almost never remember the command to do that. Perhaps its because I only do it once in 2 months or so. Thankfully my browser has me covered. I type in "git delete" and it autocompletes to links describing deletion of branches and tags.

rounce 10y ago

@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.