Defend against the waking nightmare that is git submodules #60
Conversation
sdboyer
changed the title
|
@sdboyer FYI, had to rerun the CI jobs. Made no sense why they failed and upon re-run they passed. |
|
oh yeah thanks, i meant to bump this with a note about that. i tried to kick them myself, but i didn't have perms |
|
Not to be a ball buster, but there are some fun git commands and flags here that I haven't seen before and make me wonder "what is the minimum required git version?". |
|
@tamird totally reasonable question. i had the same concern while initially writing this, but proceeded because all of these turned out to be quite old. In fact, I don't even know how old for most of them, because I didn't feel like chasing it down past the release notes reorg that happened in the git repo 6 years ago...
|
|
Great, thanks for documenting that.
…On Dec 6, 2016 17:49, "sam boyer" ***@***.***> wrote:
@tamird <https://github.com/tamird> totally reasonable question. i
expected them to be much more recent than they actually were, but they're
quite old. In fact, I don't even know how old for most of them, because I
didn't feel like chasing it down past the release notes reorg that happened
in the git repo 6 years ago...
- git checkout-index, and all the opts to it, are basically original
plumbing
- git submodule foreach was introduced in 1.6.1
<https://github.com/git/git/blob/master/Documentation/RelNotes/1.6.1.txt#L198>
- git clean -xdf appears to all be basically OG. The second -f is
necessary for killing subdirs that have their own .git, as of 1.6.4.2
<https://github.com/git/git/blob/master/Documentation/RelNotes/1.6.4.2.txt#L20>
- git clone --recursive was introduced in 1.6.5
<https://github.com/git/git/blob/master/Documentation/RelNotes/1.6.5.txt>,
along with git submodule ops learning --recursive
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#60 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABdsPGJ5fqlpOiop29u7pZ2fyOUJ-e9cks5rFeZygaJpZM4LDgKO>
.
|
| return NewLocalError("Unexpected error while defensively cleaning up after possible derelict submodule directories", err, string(out)) | ||
| } | ||
| // Then, repeat just in case there are any nested submodules that went away. | ||
| out, err = s.RunFromDir("git", "submodule", "foreach", "--recursive", "clean", "-x", "-d", "-f", "-f") |
There was a problem hiding this comment.
Did you experience the issue where a nested submodule wen't away from the git clean? I'm curious of the motivation to run this command again.
There was a problem hiding this comment.
It's the same command, but run against all submodules, recursively. If we submodule A@v1, and A@v1 submodules B. If we switch our version to something that submodules A@v2, which does NOT submodule B, then there'll be a derelict A/B dir that needs to be cleaned up. The first git clean won't get it, because it doesn't recurse - only this second one will.
|
@sdboyer I'm really like a submodule test or 2. One with and one without nested submodules. Is that something you have time to write? |
|
pretty swamped atm not sure if i'll have the time to put together the fixture repos for that this week |
|
glad we added tests :) |
|
please kick those tests - failure was erroneous |
|
@sdboyer kicked and now passing |
Seriously, this makes me want to die. But Masterminds/glide#698 is correct - we can't just ignore it.
I think this covers it. Probably. Maybe. ugh. I'm just so super glad that every single checkout/pull will now have to run three additional commands afterwards in order to be safe.