That's not an unreasonable question. But so is this one:
You can run:
git write-tree
git commit-tree -p HEAD -m message <hash-from-git-write-tree>
git branch -f <current-branch> <hash-from-git-commit-tree>
This does the same thing—well, it does if there are no errors—as:
git commit -m message
so why do we have a git commit command at all?
Here's a followup question: Which of these is easier to use?
The git clone command is actually equivalent to running up to six commands, five of which are Git commands. The six steps involved in git clone are:
mkdir path, to make a new empty directory in which to run git init. (This step is skipped in the special case in which you give git clone the path name of an existing but empty directory, in which case it uses that.)
git init, to create a new empty repository in the new directory.
git remote add remote url, where remote is from your git clone option -o, or is origin if you did not specify this option, and the url is the one you specified in the clone command.
Any additional git config commands from options supplied to git clone.
git fetch remote, to obtain commits from the Git at the supplied URL.
git checkout branch, where the branch is the one you specified with the -b option in your git clone command, or a branch specified by the other Git if you did not specify a branch, or master if the other Git does not specify any branch.
The git clone command also handles various errors that can occur during this process that you would otherwise have to handle yourself.
The git pull command is equivalent to running git fetch followed by a second Git command. That second command is usually git merge, though you can tell Git to use git rebaseinstead. But git pull has one more special mode: when you git pull into a completely empty repository, as you did in your question, it can run git checkout as its second command instead of either of the other two.
Note: unlike git clone, where it's very rare to need anything between the six steps, with git pull it's pretty common for me to need to inspect the commits that git fetch obtained before I run a second command. So I generally avoid git pull entirely, because it forces me to choose the second command to run, and to run it immediately upon the completion of the fetch step, when I would like to do something else after fetch, before I choose whether to use merge, or rebase, or something else entirely.
