Firstly, I agree that Git has a learning curve. However, trying to learn anything based on man pages alone is not a good idea, in my opinion man pages are for reference and not a substitute for more extensive documentation. Of course, sometimes man pages are the only document one has, but this is not so in the case of Git. I myself am not a Git expert, but after reading about what problems people have with Git, it feels like people should perhaps not go for the most exotic commands by default, and they should use a topic branch based workflow. And they should read the Pro Git book and I mean this in a good way :)
As for the switches, one can just as well use "git branch -v" to list branches, I usually pipe to grep if looking for a branch. For the "git remote", it actually does show you the remotes without any switches, but the URL of the remote is not the remote... To see the URLs you'll need the verbose switch. Maybe this is right, maybe not, I do think it makes sense.
The two dashes is actually not a Git peculiarity. It comes from getopt and POSIX.2 to signal the end of options. Compare with e.g. to rm a file that's called "-rf", you'll have to do "rm -- -rf" in the shell.
As for the intern, just tell them "Git reset moves backwards in commit history". Of course there are details (and you can get back to the future with e.g. git reflog), but it should be accurate enough description to an intern who is new to Git, since that's what "git reset" is mostly used for anyway. IMO "git reset -p" and such are somewhat advanced usage.
The problem with the Stack Overflow link is that Git is not tracking that upstream branch, just because the local and remote branches happen to have the same name after a push does not mean they are the same and should be tracked. I'd argue that if one works with topic branches, that kind of situation is kind of remedied automagically through the workflow... Anyway, Tzen's answer there is the correct one (when including the typofixes in the comments).
Also, thanks for the link to the Git man page generator, it's great!
Firstly, I agree that Git has a learning curve. However, trying to learn anything based on man pages alone is not a good idea, in my opinion man pages are for reference and not a substitute for more extensive documentation. Of course, sometimes man pages are the only document one has, but this is not so in the case of Git. I myself am not a Git expert, but after reading about what problems people have with Git, it feels like people should perhaps not go for the most exotic commands by default, and they should use a topic branch based workflow. And they should read the Pro Git book and I mean this in a good way :)
As for the switches, one can just as well use "git branch -v" to list branches, I usually pipe to grep if looking for a branch. For the "git remote", it actually does show you the remotes without any switches, but the URL of the remote is not the remote... To see the URLs you'll need the verbose switch. Maybe this is right, maybe not, I do think it makes sense.
The two dashes is actually not a Git peculiarity. It comes from getopt and POSIX.2 to signal the end of options. Compare with e.g. to rm a file that's called "-rf", you'll have to do "rm -- -rf" in the shell.
As for the intern, just tell them "Git reset moves backwards in commit history". Of course there are details (and you can get back to the future with e.g. git reflog), but it should be accurate enough description to an intern who is new to Git, since that's what "git reset" is mostly used for anyway. IMO "git reset -p" and such are somewhat advanced usage.
The problem with the Stack Overflow link is that Git is not tracking that upstream branch, just because the local and remote branches happen to have the same name after a push does not mean they are the same and should be tracked. I'd argue that if one works with topic branches, that kind of situation is kind of remedied automagically through the workflow... Anyway, Tzen's answer there is the correct one (when including the typofixes in the comments).
Also, thanks for the link to the Git man page generator, it's great!