[snarfy]

You spend all this time figuring out how to make git do what you want using this general format:

    git <git-command> [args]

You would expect to do the same thing with a submodule, it would be:

    git submodule <git-command> [args]

But no, submodules have their own set of commands. It's like it's purposefully obtuse for no good reason.

[magicalhippo]

> It's like it's purposefully obtuse for no good reason.

At least it's consistent with the rest of git then...

Git is one of those tools I just can't muster the willpower to truly learn. I use SourceTree and hope for the best, and search the web frantically when something weird happens.

I used Mercurial from only the command line for many years, never felt I needed a GUI. But git, there's just something about it.

[ghayes]

My common advice is: bite the bullet and learn it. Specifically, delve deeper past the porcelain commands and understand what they do. Also, for a while I stopped using “git pull” and used “git fetch” and manually managed merges and branch tracking (a lot of “git reset —-hard origin/branch-name”). Once you get it, you will be a lot more productive. You’ll still have to deal with obtuse commands from time to time, but you’ll have a better model of what they should do and can check if they are doing it right.

[rectang]

The Git command line interface is confusing, but Git's data structure design — a content addressable store — is relatively simple (and very interesting!).

I went through the book Pro Git three times leading three different training groups, and I was pretty comfortable with it. But what took me to the next level was prepping a talk for Papers We Love San Diego which explores everything that happens inside the `.git` directory when you initialize a repo and perform a couple basic commits: https://www.youtube.com/watch?v=fHSZz_Mx-Uo

[magicalhippo]

I guess part of the issue. I just don't interact with git enough that it matters much.

I might spend half an hour every now and then trying to figure out right incantation for this specific issue, but overall SourceTree just tells git what it needs to hear and I can carry on with what I really want: code.

[ghayes]

Sure, but I might argue that you'll spend _even less time_, in aggregate, with more productivity if you understand the tool better. This is particularly useful when, for example, you're good at saving your peers time by properly rebasing and/or cherry-picking your commits.

[kelnos]

That doesn't really make sense to me. `git submodule` is for managing (adding, removing, updating) the submodule, not for doing any random git operation on the submodule.

[snarfy]

Why is it

    git submodule update

and not

    git submodule pull

I understand pull in this context would be a submodule command, not a git command, but why use different terminology from git for what is the same idea?