RFC: rename the binary to git-conventional-commit, retaining git-cc as a symlink/alias

[SKalt]

The name git-cc doesn't tell you what it does. cc could stand for anything, from email's carbon-copy to cubic centimeters. Worse still, cc is impractically short for tab-completion. git c<tab> brings up all the git subcommand which start with c, with cc somewhere below the top of the list.

Proposal: rename the binary to git-conventional-commit, with git-cc retained as a symlink and/or git-alias. That way, git conv<tab> will complete to git conventional-commit without additional configuration, while git cc [...] will still work normally. Based on my initial experimentation, symlinking git-conventional-commit -> git-cc breaks git tab-completion in bash/zsh, likely due to the symlink's file-mode being different than just a user-executable file: I got lrwxrwxrwx

To avoid renaming the binary, you could git config --global alias.conventional-commit 'cc'. However, that's another installation step in a tool that's meant to be maximally convenient.

To my ~1-2 users: Thoughts?

[SKalt]

Thanks to all who contributed -- there were some good ideas in there! Having listened to the community's concerns, I'm going to go straight ahead and do what I intended to do anyway. /s

[SKalt]

update: turns out adding zsh/bash completion requires adding or appending a new bash/zsh function or script to a specific location in the host filesystem. I'm uncomfortable implementing that as the default: I'd rather maintain a single binary rather than wrangle script that run on package installation, symlinks, etc. I'm going to add make a note about completion in the readme and maybe add an aliasing option to the download-and-install script.

[SKalt]

It looks like it would be possible to

1. create a git-conventional-changelog setup [git-alias|$SHELL-completion] subcommand
2. run said git-conventional-changelog setup subcommand in a postinstall hook defined in a linux package postinstall script