Fail with diagnostic if submodules don't exist

[travisdowns]

Many users will probably just git clone followed by make and the submodules will be missing in that case, but the failure mode is a bit obscure: you'll get some weird error as you try to make a submodule that doesn't exist.

We should just check if (some) submodule exists and if not print a diagnostic recommending git submodule update --init.

[nemequ]

Or just something like (untested, typing on phone):

submodule/file: .git
    git submodule update --init --recursive

I guess it may be a bit too magical for some people, but I think it makes sense...

[travisdowns]

@nemequ - duh, not sure why I didn't think of that? I guess I have "source control" and build as separate concerns in my head, but this totally makes sense.

Once question, I'm not following the .git in the prerequisite list. What's that for?

[nemequ]

Because if they download a tarball or zip from GitHub it won't include the git files (or submodules). GitHub's tarballs are broken if you use submodules, and there is no way to disable them. They're aware of the issue, but have no plans to fix it, or allow you to disable generated archives.

On August 3, 2018 7:48:55 AM travisdowns ***@***.***> wrote: @nemequ - duh, not sure why I didn't think of that? I guess I have "source control" and build as separate concerns in my head, but this totally makes sense. Once question, I'm not following the .git in the prerequisite list. What's that for? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Sent with AquaMail for Android https://www.mobisystems.com/aqua-mail

[travisdowns]

@nemequ I see, so in the case a user downloaded a tarball, they would get some error like "no rule to make .git" or something? Maybe it would be better to just include a recipe line before the git submodule update to fail with an error message if .git doesn't exist.

Git submodules are not really turning out to be as nice a way of including other projects as I had hoped. In particular, the fact that when you do a git pull or whatever and the submodules have been updated on the remote (which I do frequently), it won't update the submodules by default is ... insane IMO.

[nemequ]

@nemequ I see, so in the case a user downloaded a tarball, they would get some error like "no rule to make .git" or something?

Right.

Git submodules are not really turning out to be as nice a way of including other projects as I had hoped. In particular, the fact that when you do a git pull or whatever and the submodules have been updated on the remote (which I do frequently), it won't update the submodules by default is ... insane IMO.

That's actually something I like about submodules; if the submodule's API is unstable you can still use them. That said, I wouldn't mind if there were a way to automatically track a branch for submodules you trust won't break their interface.

Also, it may not just be API breaks you have to worry about. I've had API/ABI stable modules break because of files being added/removed… you may need to use your build system instead of theirs. Even if you do use theirs, usually build systems aren't included in the API guarantees.

[travisdowns]

That's actually something I like about submodules...

I probably didn't do a good job of explaining what I meant. You are talking about the feature where you point to a particular commit of a submodule and until you explicitly update that in the parent project, it will stay pointing there. That is great and necessary and I wouldn't want it any other way.

What I'm talking about is that say you and I both have uarch-bench cloned locally and we are both up to date. I make a change that requires an update of submodule A from commit abc to def, and I push that change. Now a new user who clones the project after that has no problem, they'll get version def of A when they do their clone --recursive or whatever. You, however, when you do your next git pull will not get your submodule ref updated to def, you'll still have abc. Whether that breaks or just silently corrupts something or whatever totally depends on the details - but it sucks!

It means that a simple git pull is no longer enough to really stay in sync with the remote, when it comes to subprojects. Basically I think git should behave by default the way it does when you set git config --global submodule.recurse true.

[nemequ]

Oh, yeah you're right that's definitely annoying.

FWIW git-radar makes that sort of thing a bit easier to spot.

[travisdowns]

I think I am just going to get rid of all the submodules and move a git-subtree based approach instead. I have used it on other projects and it seems better in almost every respect.