Hacker News Reader

Comment by newnewpdro | Hacker News Reader

The worst thing about using git submodules is it's no longer a simple matter of `git clone url://to.repo` to clone a project. Then, if the person doing the clone is unfamiliar with submodules, it's unobvious how they go about fetching the submodules separately.

The next worse thing about submodules is when you add a submodule to a project, if that submodule has submodules of its own it's completely unobvious how to perform the submodule addition recursively. The `git add module` command doesn't recognize `--recursive`. IIRC the way you work around this is via the magic incantation `git submodule update --init --recursive` after adding the submodule having its own submodules.

I really like submodules conceptually but the current UX surrounding their implementation is awful.

View on HN

You can clone with submodules in one command: https://stackoverflow.com/questions/3796927/how-to-git-clone...

But I agree, maybe it should be turned on by default.

try using https://github.com/ingydotnet/git-subrepo that gives you the ability to simply clone a repo.

The point is that git doesn't do the right thing.

A random git user with just the URL for my submodule-using repository isn't going to know to use some special thing to clone the repository. They're going to run `git clone URL` and then be frustrated by the results.

Let's report it in Git's bug tracker ... oh wait.

not sure what your "oh wait" is about... they apparently take bug reports over email. from https://git-scm.com/community:

> Questions or comments for the Git community can be sent to the mailing list by using the email address git@vger.kernel.org. Bug reports for git should be sent to this mailing list.

That's not a bug tracker IMHO.

For the vast majority of users git is bug free. If there is an issue with git nowadays its highly specific and well suited to be handled in a mailing list.

This also makes it easier for the git devs to focus on actual development and not explain git to people unwilling to use google (the same people are to lazy to use email).

I am curious... has anyone ever tried to convince git to fix the defaults?

Of course there's a little more than just this wrong with submodules but it seems like given how much hate they get, that someone would be interested in actually fixing them

my point was, that if you use git-subrepo instead, then you get exactly that.

git already supports `git clone --recursive[-submodules] URL`, there's no need to use git-subrepo to achieve the recursive clone.

The problem is the requirement of prior knowledge about the repository's use of submodules. The plain clone won't even report any sort of feedback about the submodules being present and skipped, nor any hint as to how to retrieve them: `git submodule update --init --recursive`.

The presence of git-subrepo and `git clone --recursive` is of little consequence from the perspective of the many users who are now familiar with the ubiquitous `git clone URL`.

Does github tell people to use git-subrepo to clone a given repository? Hell, does github even tell people to add `--recursive` when a repository uses submodules? I haven't checked, but don't recall ever seeing it do so in the past.

These are not difficult technical issues, it's just the sad state of the submodules UX in git. I presume it will improve eventually.

with git-subrepo, you just clone as normal, you don't even need git-subrepo installed. It just looks like a normal repo. You require 0 prior knowledge. You can update all the code in all the subrepos as a normal repo. Never ever knowing it has subrepos. The only people who need to know and have git-subrepo installed are those that need to sync the subrepos.

Thank you for the clarification, sounds like it's worth taking a closer look.

Reply on news.ycombinator.com