Update submodules to point to current branch

[killermoehre]

Updating both submodules bootstrap and Font-Awesome to their current commit in the respective branch.

Closes: #822

[killermoehre]

I signed the CLA. Please re-scan.

[LisaFC]

Looks good, @deining can you take a look as well? Preview looks fine.

[deining]

Docsy pulls in bootstrap 4.6.1 in layouts/partials/scripts.html`:

<script src="https://cdn.jsdelivr.net/npm/bootstrap@4.6.1/dist/js/bootstrap.min.js"
    integrity="sha512-UR25UO94eTnCVwjbXozyeVd6ZqpaAE9naiEUBK/A+QDbfSTQFhPGj5lOR6d8tsgbBk84Ggb5A3EkjsOgPRPcKA=="
    crossorigin="anonymous"></script>

Dosy repo, HEAD has submodule bootstrap @ 043a03c
Revision 043a03c is tagged as v4.6.1, so everything looks fine to me here.

This PR wants to move submodule forward to 349a373f, current HEAD of branch v4-dev, 17 commits ahead of tag v4.6.1. I don't see a real reason for this change since script and submodule are out of sync then. Probably it won't do harm, but what is the motivation behind this? Resolving #822? I don't know the exact setting there, so it's hard to tell what's going on and what causes the problems described in #822. However, my feeling is that there must be another way to resolve issue #822. Unfortunately, without knowing further details, I'm not really able to help out to resolve #822. I guess we should implement modules and @killermoehre should discard submodules in favour of Hugo module 😉 .

[killermoehre]

Well, if the branch shouldn't follow v4-dev, but should point to the tag v4.6.1, than I think this is an issue in of itself. I mean, what is .gitmodules if not a clear pointer to which code should be used?

I will check out Hugo modules. I took over some code from a colleague, so I don't know about it, yet.

[LisaFC]

Hmm, this kind of thing is definitely an argument for using Hugo modules...

Let me check when we updated to 4.6.1 for Bootstrap. Our major concern with Bootstrap is not going on to v5 yet as we don't quite support it yet (one of our roadmap items!).

[deining]

Frankly spoken, I'm a bit skeptical whether we really should merge this PR. I would recommend to merge #801 instead, which was just finalized by me. Once #801 gets merged into master using docsy theme as Hugo module should work, so @killermoehre can switch his site to make use of docsy as module. As side effect, we get immediate feedback whether #801 works as expected (I'm confident it does).

[chalin]

I don't see a real reason for this change since script and submodule are out of sync then.

I agree with @deining on this. We want the script and submodule to be in sync.

@killermoehre writes:

Well, if the branch shouldn't follow v4-dev, but should point to the tag v4.6.1, than I think this is an issue in of itself.

The submodule branch lets git know which branch to track for the submodule, not the specific commit on the branch that is currently being used. The commit info is stored elsewhere.

I'll close this now that #822 is being addressed differently.

[killermoehre]

@chalin are you sure the tracking works as expecting, because apparently git can't find the branch it tries to track. Regardless of #822, I think this is still a problem to talk about.

What is the expected behaviour of git submodule update --init --remote? According to man:git-submodule, --remote means that git queries the remote-tracking branch, which it obviously can't find. This is a problem in of itself.

By using update without --remote, git uses the SHA-1 tracked in docsy to download the submodule and this local SHA-1 seems to have diverged from the upstream bootstrap/v4-dev branch.