I just wrote a quick but functionally decent implementation of git-cp(1), a missing subcommand that Subversion users would certainly get used to.  While I desperately wanted it I could imagine why it is not part of the Git core.  There are many forms of changeset that could make it difficult for SCM to trace history, and keeping track of file copies would only handle a small part of the problem.  For example, you could merge two files into one, move a portion from one file to another, or split a file into two, and recording a hint that a file copy is done would only serve its purpose in the last case.  The designers of Git had the insight to recognize that and instead of adding a feature to record a copy, they equipped git-log and git-diff with copy/move detection so that a copy can be found when they look back the history, making recorded hints unnecessary as the detection method gets mature enough to work effectively.
But, but. I had been tired of typing cp a b && git add b every time I feel like using an existing file as a template for making a new file, and thought it would feel great if you could just say git cp a b to start working on the new file quickly. Some may say the name git cp is misleading but it is just as evil as git mv that is too just a type saver. Plus, git-cp is made not to overwrite an existing file or copy a file to outside of the repository, so it is safe to use.
I also wrote git-touch(1) for a similar reason. Whenever I want to create a new empty directory, I can say git touch log/.gitignore instead of a lengthy sequence of mkdir log && touch log/.gitignore && git add log/.gitignore. There’s also git-untouch(1) to undo it when you have made a typo or changed your mind on the new file path.
These are all dedicated to those who joy in typing less.