I like a lot of these things for sure. The only thing that I really wish they'd do that I've seen no sign they plan to is move git-subtree from contrib into the main distribution. It's such a useful thing.
Is there any intention among the Git developers to ever make --recursive a default option for git clone? (This is an option that causes git clone to recursively clone any submodules as well as the top-level repo.)<p>Sure, arguably there are fundamental issues with submodules that you won't ever solve, and some people might prefer subtree to become the default. (I won't get into that argument here as there is another thread addressing that topic.)<p>But the fact still stands that a lot of the ugliness of submodules comes from the fact that the UI forces users to learn a whole extra set of commands, while the regular commands are largely oblivious to the existence of submodule. If I make a Git repo with submodules, I can't just pass a link to my Git-novice friends and have them clone it, because the UI for submodules is separate from the main Git UI. Arguably, for users who don't need to actually touch the submodule, the fact that the submodule is there should be invisible from the perspective of the UI. Although Git has been gradually getting closer to this being true, it is not currently the case (clone being an example of one command which is not aware of submodules by default).
Is it just me or "simple semantics" is not at all simple? Compare with:<p><pre><code> hg push -- pushes everything to "default push location"
hg push -r . -- pushes currently checked out branch
hg push -r foo where -- pushes foo to where</code></pre>
Minor feature that's really nice: the pull.ff config setting. I had made an alias for doing that manually, now I can start actually using git pull again.
I like the "add" is more inclusive by default. But does this mean that "add -p" also can add untracked files? (If not, it seems inconsistent to me.)