Thanks for the reply!
I agree that some of the commands have a very large array of options. I see many these options as very specialized tools (and certainly don't claim to know all (or -in some cases- most) of them). I, too find the "git config" command to be largely useless. Its value is in scripts or in Git frontends. Also, the git-config manpage has a complete listing of all valid git config options. So, there's that. :)
> Commit, checkout, and reset seem rather more complicated than necessary and don't do anything useful in their default forms...
When called with no args, commit records changes staged with add/rm/mv in the local repo's history. Checkout changes the tracked contents of the working copy to that of another point in the repo's history (so it is meaningless to call it without an argument), and git reset is destructive (and has no --force option), so it makes sense to require an argument. [0]
In regards to commit and checkout:
I came to git by way of Subversion. These two confused me for quite a while. What helped me to understand the logic behind them was to realize that -unlike SVN- git has
* The working copy, which is manipulated with a bunch of commands
* The area where changes that will be included in the next commit live, which is cleared out after every successful commit, and is manipulated by add, rm, and others
* Your local repo, which is manipulated with commit and checkout
* One or more remote repos, which is manipulated with push, pull, and merge
But maybe you already had this solidly in mind, and this explanation was a waste of your time. :(
> As always, trying to read the documentation leaves me with less understanding than I had before I started.
Have you familiarized yourself with a significant fraction of git's vocabulary? The man pages became much clearer once I did so. [1]
> ...for reasons I cannot comprehend they also get involved in merge resolution, where they perform tasks with no visible relationship to their names or their normal jobs.
Oh. That's because a merge operation adds a series of commits from one or more branches into another branch and effectively makes a new commit with the result of the operation. If conflicts can be automatically resolved, then they are. If they cannot, then it's up to you to stage the changes you want to see in the merge commit (using add and friends) just like you would do when preparing any other commit. Does that make sense?
> I have no idea what reflog would do; is there a flog command too?
Nah. It's a command for examining and manipulating the reflog, which is -effectively- where git makes a record of every change that happened to your repo. You pretty much never need to use the command, but I have used to see just how git handled a set of complicated squash and commit reorder operations. From the man page:
Reference logs, or "reflogs", record when the tips of branches and
other references were updated in the local repository. Reflogs are
useful in various Git commands, to specify the old value of a
reference. For example, HEAD@{2} means "where HEAD used to be two moves
ago", master@{one.week.ago} means "where master used to point to one
week ago in this local repository", and so on. See gitrevisions(7) for
more details.
If you've gone on a mad history rewriting spree and have confused yourself (or simply accidentally moved a branch a while back and can't remember where it used to point), you can use reflog to trawl through the change history to save yourself.
> I am generally more inclined to use stash or a second working directory than to deal with branches, since it's less busy-work.
I'm curious. What busy-work do you have to do? I typically just have to do: "git branch whatever; git checkout another-branch; git branch -D some-other-branch".
[0] Though -conceptually- a substantial portion of reset's functionality overlaps with checkout's functionality. So, that's silly and nonsensical.
[1] Not that I'm implying that such a thing is be required to use git, mind.