Git Submodules with Shelley

Speaker 0: Hello, and welcome to learning things I love to hate. In this show, I stop avoiding tech topics that I have been avoiding for one reason or another with the help of my friends and colleagues who know more about them than me. And today, my dear friend Shelly is joining me to talk about Git submodules. Shelly, would you like to introduce yourself?

Speaker 1: Hello. Thank you for having me. I am very excited to help teach you about things that you historically love to hate.

Speaker 0: Potentially in the future as well. We'll see.

Speaker 1: Oh, fair enough. I'm Shelley. I work on Electron at Microsoft, and we have to do a lot of gross stuff with Git. So, I am hopefully here to help talk about one of the more commonly considered gross things to do with Git Git submodules.

Speaker 0: I'm glad we are setting the scene adequately. I normally start these by just giving a bit of context as to what I know or what I think I know. We can dismantle that if it's wrong. But just to kinda set the scene. So get sub modules.

I have seen them a few times in my career, and I've literally never once in my life got them to act in a way that I think they should. My understanding is you can have 2 distinct Git repositories and you have, let's call it, the child and the parent for all intents and purposes. And Sure. You can kind of sim or it's almost like sim link the child one into the parent one. So it appears in this repo, but the actual content exists over here.

There's some mechanism to sync them that never works. It confuses my command line. And the reason I have avoided them is, as I said, they just seem really complex. And the other part is I now at least at direct us, I'm working in a mono repo, one big repository with directories for get submodules is in, like, you know, that the value of get submodules is in, like, you know, share abstracting bits of your code out to share in multiple places. Monorepos may do the the same thing or have the same characteristics without this this intricate git bit.

So that's what I think I know. We don't need to address those straightaway. But at some point over the time we speak, it'd be good. Can we start by talking a bit about what they are, why they exist? And maybe we'll go on from there?

Speaker 1: Yeah. So basically, you had kind of the rough gist of it right, which is that git module or git submodules are basically like a repository, like a git repository inside of another git repository. This basically allows you to keep, obviously, as you said, 1 git repo as, like a subdirectory of another one and then work on them functionally independently. The Git information or basically metadata about the child repository is tracked in a file in the parent repository called dotgitmodules, which keeps a track of the commit that you have checked out in the child repository and allows you to basically kinda keep those concerns separate. I guess kinda writ large my opinion about, I guess, Git and submodules in this department generally is that Git itself is a tool.

So Yeah. I don't really think it's the case that, like, Git submodules are, like, the solution to a problem as opposed to essentially kind of being one of the many tools in your toolbox you can kind of potentially use depending on the structure or nature of your project to deal with potentially having, like, a a team that works on different things but wanna get work done in tandem or you need certain updates from whatever is being worked on in the submodule. But as kind of with many other things, there's situations where I think they'd be, like, okay fits and situations where they'd be not super great fits. Specifically, I think that they were, I mean, created originally for a couple reasons. I mean, I don't know the actual, like, Git history.

I'm sure I can look through my horrible Git mailing list till I come up with this.

Speaker 0: History lesson. All good.

Speaker 1: But, yeah, primarily, I would say, like, they kinda serve to keep code separate, to let you develop code independently, and to potentially let you reuse chunks of logic between different robot stories.

Speaker 0: Sure. Interesting. There's a few things he said there. One was, you know, it allows I've got I've got my pen now, so that was serious. A pen with a a literal bend in it.

See that? These aren't meant to do that. Anyway, first thing you said is, like, yeah, teams can kind of work in tandem, but separately. I don't see why the standard get workflow wouldn't enable a very similar thing. I I now understand the case of the parent repository in the latest example I use I had didn't actually contain the files that contained, like I said, basically a similar reference to where the file actually is.

And maybe that's a little bit funky for how, you know, get clients render sub modules where it feels like it's here, but it isn't really. It's just a reference to what's happening over there. You also mentioned checking out what's happening in the child repository. I think he has a piece of the workflow. I just didn't know.

Maybe that's why I've struggled with it. Well, I update it over here, and now it isn't updated over here because I need to take some action in the parent. And the final thing you said was sharing logic, like sharing chunks of logic. And I I don't see why that has to be get submodules. But I guess that's if your application is spread over multiple repositories.

That makes a bit more sense.

Speaker 1: So, I mean, my kind of honest take is that I don't think it does. Like, I don't actually think that is the best way to maybe I'm kind of keep it going by a large opinion here, but I don't necessarily think in a lot of cases that is the best way to track separation of concerns Mhmm. Or kinda deal with that generally. One, I kind of think the biggest issue with them, which is kind of what you brought up at the beginning, is that they're a humongous foot gun. It's kind of hard for people, especially people that, like, aren't don't necessarily have, like, a super in-depth concept of, like, the or, like, a mental model of Git, how it works.

Because one, you need to learn a couple new commands. You need to learn sub module init, sub module update, sub module status, whatever, what have you. But I think it's very easy to forget, for example, that changes you make in the submodule aren't necessarily tracked in the parent unless you're actually currently in that subdirectory. So I think it's pretty easy to be you know, make some changes in the the sub module and then go back up to the parent and then forget to commit the the metadata change. Because itself, it's it's a commit, but it's not a traditional commit in the sense that it's like a snapshot of the current working directory.

It's basically like a a a pointer to, like, sub module metadata, essentially.

Speaker 0: Interesting.

Speaker 1: I also think it's pretty easy to end up getting in way over your head with complicated workflows around submodules. One example is that it's actually possible to have nested submodules. I don't know if you know that.

Speaker 0: I wish I didn't, but now I do.

Speaker 1: Yeah. So you could have nested submodules. And so, basically, every time you check out a new project, you need to so also god. Lots of times here. So, basically, when you first clone a project, right, that has a sub module, you clone it down.

You don't actually already have all the files that are contained in the sub module. When you first point it down, you'll end up with a directory where the sub module will live, but the directory itself will be empty. There is a way god. Let me hold on. Oh, yeah.

Just recurse submodules. So when you originally clone a project, it's possible to pass a command to actually initialize the sub modules, so it's not really one that's most people know I would argue, which is dash dash, recurse submodules, I believe. And that'll kind of initialize the submodule. Hold on. Double check that.

Speaker 0: But when you say initialize the sub module, you mean it will go and push those files down for you at the same time?

Speaker 1: Yes. So essentially when yeah. Like I said, when you first clone it down, you end up with the directory where the sub module is, but the directory is empty. And if you're in a project and you haven't, like, looked at the if it's like a new project and you have you don't really think about looking for the git modules file, you might not actually be super aware that it's there that you do need to actually initialize the submodules. So that's also something that you as a project maintainer have to make super clear to people who are looking to contribute, which I don't think is all necessarily intuitive.

I actually ran into this a while ago. I was trying to do a repro for a problem that I was working on at work for the project I maintain. And I didn't realize there was a submodule, and it kept, like, airing on missing files. And it took me, like, a good 5 minutes to be like, oh, I have to I have to initialize the sub module. And then it was fine, but, like, just as, like, a short term example, it just it's not super intuitive, and they didn't actually mention it.

I know they were contributing that.

Speaker 0: Yeah. And so so just so I understand. So I'm gonna use parent and child terminology to talk about sub module versus the the repository which uses that sub module. Yeah. A sub module is just a git repository, a separate git repository.

Yeah. When you clone a repository in the standard way, you end up with the directory where the sub module code will live, but it's empty. You need to run further commands in order to grab the latest version of what's happened over in that repository. But if you do work in the child, in the sub module, in the meantime, when you're in the parent repository, that that change isn't reflected. Even if you just pull for main, it isn't reflected.

You need to actively and consciously go out and grab the latest status of the submodules, the latest commit, and bring them over.

Speaker 1: So, yes yes yes and no. So, basically, the answers.

Speaker 0: Let's start that way. Yes, but also

Speaker 1: I love to answer things with yes and no. So, anyway, let's say, you know, in the the super super repository super directory, whatever Yeah. Yeah. So you'd pull down let's say you make a change to the subdirectory, and then you commit that and you update the metadata. Right?

And then you push that as a commit. You've updated the commit that the child get repository points to, and then you've pulled that down. Mhmm. So you you have pulled down, like, a a sign pointing to the change. But in order to actually have that change reflected in your submodule, you'd have to then run git submodule update so that git then updates the reference that that submodule points to.

No.

Speaker 0: Hang on. We gotta go back. We gotta do that one again. Sorry. So alright.

So I understand that to grab the latest code, there is a get some module update. But before that, I got a bit lost. So but but the reference inside of your super repository or parent repository, that doesn't change automatically. You've gotta do that too. There's almost like a 2 step thing.

Speaker 1: Yes. Correct. Which is actually what makes it kinda hard. So okay, so let's say we're starting from scratch. Right?

I have a repo. It has one sub module. And I'm I'm a new contributor. I haven't really worked with this repository before, so I clone it down. And let's say my, god, this is gonna be, like, pointless names time.

My submodule's name is, like, bear paw. I don't know.

Speaker 0: I don't

Speaker 1: even know where I got that from.

Speaker 0: Take it. It's it's I

Speaker 1: don't know. So in my primary repository, bear bear Paul. Bear Paul is a bear.

Speaker 0: But I got it. Yeah. Yeah.

Speaker 1: I'm following.

Speaker 0: Yeah.

Speaker 1: Okay. We're getting there. Okay. So I've cloned down bear. And then in that repository, I have my metadata file, git modules, which has a pointer to the commit that I should check out in my sub module, bear paw.

When I originally cloned that down, I'll have the directory bear paw present in the primary working tree, but it won't have anything in it.

Speaker 0: Sure.

Speaker 1: There's a couple ways that I could do that. When I first clone it down, I could run git clone dash dash recurse submodules. And that would actually initialize and set up the submodule from the get go. The other thing I could do potentially is I could clone it down like normal, and then the submodule wouldn't be initialized. And then I could just go ahead and run git sub module, update dash dash init or git put sub module init and then git sub module update.

And then I would have the current state of my primary repository, and then I would have my submodule checked out to whatever the most recent reference is.

Speaker 0: Most recent reference is. Okay.

Speaker 1: Like like, the the commit in the sub module that I want to be on, essentially.

Speaker 0: Got it. Interesting. This looks like a lot of work. Like, I'm really struggling to understand why

Speaker 1: Genuinely, it kind of is.

Speaker 0: Merits. Yeah. What the merits of this flow is. I mean, what are the other options when it comes to basically abstracting parts of logic out? Because that's really what this is the core of.

And maybe functionally to have different repositories in, like, hosted services like GitHub. So you end up with different issues, different pull requests, different project boards. Maybe that's part of the value here as well. That was actually what when I joined directors, it isn't the case anymore, but that's that's what it was. We have the docs where a repo, and we had guides which our community could contribute to.

We had those in a separate repo. So this community contributed guides, PRs, issues were separate. It didn't really make that much sense. We got rid of those and and, merged them just into one repo. And in the end, it all ended up in a mono in the mono repo anyway.

What are the other ways to do it? Depending on what your application is, you could publish, you know, you could publish bits of reusable logic, you know, like a package like a standalone package, and you can pull that in, you could have a mono repo, that's a bit of a bigger choice. I just, I'm not sure. There's a lot of complexity, even when you said you can clone it down using this additional flag. No one's gonna do that, even if it was on the end of a command.

Like, you really need to understand that this command is different from the norm to not just go on autopilot and get clone repo a repo URL.

Speaker 1: Yeah. Interesting. I mean, I think there's also, like there's a lot of ways to kind of get around having to use submodules in, like, with other things I think a lot of people don't know. So for example, there's actually a whole concept of git sub trees. It's been around since, like, 2012, I think.

I don't remember which version of git that was, but you can do that. You can also I actually don't know if a lot of people know this, so, actually, feel free to tell me if you do is, you can point to just like a straight tarball in your package JSON. We've done that a ton of times actually in Electron before when we need a specific, basically, like, commit from a project upstream that we haven't managed to get into master yet as a pull request. And so we'll just kind of, like, point to the committed just like a raw tarball, and then update it again when the PR gets merged.

Speaker 0: Interesting.

Speaker 1: So you can you can you can basically find ways to, like, point to just, like, single commits without actually having to maintain a sub module in your own package. Yeah. But, I mean, like, I would say largely speaking, the biggest issue with submodules is that the barrier to entry, like, the learning curve for them is higher in some ways than I think the benefit you get out of them. Like, they're very complex on principle. Like I said, you have to know all the commands.

Updating is pretty difficult in the sense that, obviously, if you really, like, understand and know the flow, then I think you can, you know, get the string of commands you have to write kinda down. But, like, conceptually, I think it's pretty easy to, like, again, foot gun yourself, by forgetting to commit in the, like or by committing in the sub module and then forgetting to change the metadata commit in the primary repository. And then you actually, like, reset again, and then you've blown it all away. Yeah. So I do

Speaker 0: have having to do work in lots of repositories in order to I don't know. It just feels it's so interesting. Yeah, I think I think I think I'm ending in the same place I'm starting. But I mean, we're not at the end. Yeah.

I mean, I think I'm likely going to end in the same place. I started with a greater understanding of what they are and how they work, which is great, you know, still fulfills the goal. Interesting. So the world of, excuse me, the world of Git sub modules, are there any like notable, like real use cases that you have seen where you're like, Yeah, get some modules for absolutely the right tool for this

Speaker 1: problem? To be totally honest with you, not really. We actually had a multiyear actually, one other thing before I forget is that, you could also reference just a straight up Git URL in your package JSON.

Speaker 0: Like, without

Speaker 1: actually having to do a sub module.

Speaker 0: Oh, cool.

Speaker 1: Like, there's really quite a lot of things you can do to, like, accomplish the, like, quick, like, specific hot fix. You need the dependency without actually having to maintain an entire sub module. You just you don't need to do that for large. Anyway, basically, we had probably, like, a year 6 months to a year long project in Electron to actually transition away from using submodules. We used to maintain, libchromium content, which is the prior name of basically, like, the content shell in chromium as a sub module to electron.

We switched our entire build pipeline infrastructure essentially to use, g n, as opposed to, GIP, generate your projects, which is what we used before that. And it simplified our entire workflow, like, probably by tenfold because previously so, okay. Example is let's say that we are maintaining, 3 supportive lines in Electron, say, at the time, last time we used this, it was, like, I don't know, maybe 5, 6, and 7. Let's say 5, 6, and 7. Those are supported lines.

Remember, each one of them has a different sub module, because each one of them so let's say there's a security issue. Right? And then we need to get that security issue back from the, sub module, so Chromium Chromium content shell. So from the content shell back into every supported version of electron. So that actually ends up being basically like a matrix because you need to update the submodule.

You need to get all of those, like, releases out, and then you need to update in every single supported line the reference to that change in the sub module.

Speaker 0: Yeah. Interesting.

Speaker 1: And so what we do now by, comparison is that we maintain our reference to the version of Chromium that we're dependent upon right now, in, like, a DEPS file. This is just the way g n works. And then instead, if we have to fix something really quickly, we either update the DEP or we add a patch really quickly. And it's basically removed this whole middle layer while accomplishing the exact same thing.

Speaker 0: Interesting. It feels like, yeah, maybe in 2023 When we recording this, I'm not sure if we'll publish this in 2023. Oh, happy New Year. If not, in 2023. I am not sure what the case for GIP submodules are then really when there are these other approaches.

As you said, there are these lighter weight solutions that perhaps lack the depth of complexity, for better and worse of git submodules. There are, you know, I would say, mono repos have become trendy again, and this also removes, a lot of the value perhaps seen by get sub modules. I keep going back though to is there value in having when hosted in platforms like GitHub is the value that they are treated as separate projects? Maybe for some projects, very high, you know, high engagement projects, maybe splitting those out properly is valuable over a monorepo or something like that?

Speaker 1: So I think, like, this makes you sound like a a bit of a PM, so I'm sorry in advance. But, like

Speaker 0: I I prepared myself.

Speaker 1: But, like, generally, I think the question to ask whenever you're kind of encountering some kind of a complex, like a a build pipeline problem or a Git problem or, like, some similar vein, whatever, is what problem are you actually trying to solve? Yeah. Because for any given problem, like, you know, you have this giant box of tools, and there's a bunch of different tools you can deploy to solve this problem. And realistically speaking, it's most prudent to choose the approach that even if it, like, seems more, I don't know, lowbrow or, like, simple or whatever, is gonna be the most intuitive and cause you the fewest long term problems. Like, I'm very much in the camp that the easiest solution should be the best one in the sense that if the, like, best solution requires you, like, spending a bunch of time writing a tutorial to explain why the thing that everyone is inexplicably doing is wrong, then you've screwed up multiple layers behind that.

Yeah. Yeah. Yeah. Interesting. Because, like, if you're having to tell everyone that the default thing that they think is the easiest to do that they're doing on their own is wrong, then, like, you're just failing to communicate and set up your problem in a way that the, like, simplest solution is the most effective.

Yeah. If the simplest solution is bad, then, like, you should reorganize and, like, figure out how to communicate what the, like I think you know where I'm going with this.

Speaker 0: Maybe maybe this is more of a relic of I won't say the relic of the past. I sound like an old man, but like, there are other really viable solutions that maybe weren't always apparent or not always available, at which point get sub modules were were the easiest, or were the best were the best for whatever heuristics you use to define the best. Maybe now that's less the case. How comfortable would you feel about showing me setting up a good sub module maybe?

Speaker 1: Potentially? Let's see. Potentially?

Speaker 0: We got tons of time. I feel like I've kinda get I I've got my head reasonably effectively around what they are, why I have screwed them up in the past or not been able to to work with them correctly, which was a lack of knowledge, but it is this kind of I always thought sub modules, if you work on them in the super repo, the parent repo is cool. You're just actually doing the work over here. No, you're not. No, you're not.

There's extra steps. I also don't think I've ever encountered them where they were the right tool for the job, especially for community projects, right, where you need to also consider the barrier to entry.

Speaker 1: Yeah. I mean, fair enough. And kind of in line with what you said. I think the thing that I mentioned, I don't know how long ago, like, 5, 10 minutes or so ago, about the fact that you can use just, like, straight up get URLs, local paths, or tarballs to refer to dependencies in your package JSON, for

Speaker 0: example. Exactly.

Speaker 1: I'm assuming those people watching this are gonna be working in JavaScript. Probably. Okay. Did did not always exist. Get some materials predated, I think, several of those solutions.

Speaker 0: Exactly. Exactly. And, again, what I've seen is the right way of doing things as well. I keep going back to monoreapers as an example because I work in one every day. They also solve a lot of these challenges.

Yeah. Interesting. Although, again, I do see the value, whether it's submodules or it's, you know, directly referencing a a tarball or a commit. I do see the value in splitting work up over multiple repos for many reasons.

Speaker 1: That's kind of a good example of just, like, kind of different ways that you can solve this problem. So, like, I've I think, like, originally, one of the things that I said is potential advantage of this is that you can keep these 2 projects in different Git repositories. But at this point, you know, in our year 2023, there's a lot of different ways to keep different projects and and different repositories and yet maintain those fairly fluidly between projects. Based on differences, a bunch of the different ways you could reference various packages and dependencies in your package JSON. One of which is I don't know if you all are familiar with the concept of, like, a commit ish.

Speaker 0: I've never heard of this.

Speaker 1: Oh. So it's basically

Speaker 0: like sounds remarkably uncertain.

Speaker 1: Here. I will actually just pull up the actual definition of them. So a commit ish is basically like a technically, it is a commit object or object that could be recursively dereferenced to a commit object. So you could have a commit, a tag object, a tag object that points to a tag, that points to a commit. Basically, something in, like, the vague shape of a commit.

So that's why, for example, in the link that I sent, you can say your dependency is like mocha js/mocha, hash, and then just, like, a part of a. And, like, that's good enough.

Speaker 0: That's hilarious.

Speaker 1: Your packet of manager could then figure that out and be kind

Speaker 0: of fun. Yeah. Yeah. Yeah. This is, this is a lot more complex than what I've worked with in the past.

Also, a commit ish is hilarious.

Speaker 1: Yeah. I mean, there's really quite a lot of, like, really gross things you can do if you really want to. Like, I think probably one of the worst things that I've done in my, like, personal project career

Speaker 0: I'm ready. I'm ready.

Speaker 1: Was, are you familiar with Git patch package?

Speaker 0: No.

Speaker 1: Oh, okay. So you can patch, node modules.

Speaker 0: Okay.

Speaker 1: And you basically keep the actual patch as a, like, commit file in your primary repository directory. But, if you really need to, like, quickly and dirtily change a package that you don't maintain a don't control Yeah. Then you can basically just, like, patch it locally in your own directory.

Speaker 0: That's kinda cool. By the way, I never knew that existed. Because occasionally, you do need to do this. Ideally, the upstream dependency, the down the downstream dependency terminology. The downstream I think.

Up sure.

Speaker 1: Downstream would be things depending on you.

Speaker 0: Got it. That's the upstream dependency. Authors will handle it. But yeah, you can't always and yeah. And obviously, you don't wanna do the work in your note modules folder, because you know, you often don't check those in.

That's really interesting just as an aside.

Speaker 1: Yeah. It's it's gross, but it's, like, dirty and effective. But for example, similarly, now if you wanna solve that same problem in, like, the many tools same problem approach, then you could also forecast repository, and then make the change, push a commit, and then reference the commit as a, like, URL in your package JSON. Same thing.

Speaker 0: Yeah. That definitely sounds worse.

Speaker 1: So I guess the difference, for example, would be, like, you know, in the problem solving vein. Okay. Let's say I have this opaque commit. If you're first cloning that down, you might not actually have any idea that I've made some kind of a weird change to the default thing that I'm depending upon. Whereas, for example, if you use patch package, then it's really obvious to anyone who's cloning down their repository and looking through the directory contents that I've made some kind of a change to a dependency.

So it all kind of depends on, like, what so for example, in a personal project that I know no one else will ever touch until I'm dead, I would be much more willing to today. To do yeah. I'd be much more willing to do some, like, nasty, little commit that I've put into a fork or something because I don't really care that anyone else knows that I've done. So Whereas if it's something that someone else is working on, I'd probably do something more like patch package. And then in the patch description of whatever, you know, patch file is that I'm checking into my working tree, I'd probably include a link to some upstream PR to make it more obvious to people contributing to the project that I've, like, done something nasty to a dependency, and I'm trying to get it upstream to get rid of the badge.

Speaker 0: Yeah. Interesting. Excuse me. So Electron used to use GitLab modules. And you said that there was a long term project, to I don't know in the world of electron whether it counts as long term, but feels pretty long to remove git submodules.

So what what did you replace that with?

Speaker 1: We replaced that with a, with basically it's it's called g n. It was a successor to so basically, GN is a meta build system, essentially. We basically replace our build system, from JIP for, for example, Node still uses. Have you ever heard of Node JIP?

Speaker 0: Yeah. Yeah.

Speaker 1: Yeah. So a dot JIP file describes basically how a project is built, its dependencies, what sources and files are included, flags that should be built with, etcetera, etcetera. Basically, replace that with, GN, the system. So it used to be the case that you would clone Electron down, and then you would, run and, initialize the sub module. And then, basically, it made it really, really hard to do Chrome updates.

It was during the area, the era where for a long time, Electron was quite behind, and we're, like, 10 or so versions behind.

Speaker 0: Mhmm.

Speaker 1: Chrome proper or chromium proper. And now we're basically typically constantly, and I would actually really significantly give credit to the fact that we use this build system now or this meta build system as a way to do that because what we do now is we actually you actually don't clone down electron directly. You, essentially clone I'm trying to figure out, like, the best way to explain this. We actually, like, built our

Speaker 0: own try

Speaker 1: it, and we keep going around. I'll ask questions. Built our own, like, build tools thing. We have our own, like, tool wrapper for initializing and setting up Electron that we all built because we also we discovered at the point over the course of probably, like, a year that we all had our own really sorted set of scripts to do this in, like, all subtly different ways. We were like, we should make one toolkit.

Speaker 0: Mhmm. Because

Speaker 1: we're all just doing these same things and just, like, suddenly grocery ways. But basically now Electron is a directory inside of Chromium. That's how we Okay. Build it. So when you, like, are working inside electron, you're working inside or basically, what we've made is a new subdirectory or, like, not a subdirectory, like a new top level directory within Chromium.

Speaker 0: Cool. So you gain access to, yeah, the the, as you say, the tip of tree.

Speaker 1: Right. But also all those files are all around you. So if you wanna make a quick change in Chromium, in the past, it was submodules. So you couldn't, like, you couldn't do it really easily. It was miserable.

Whereas now, if I wanna go change something in Chromium or, like, do a bunch of logging to, like, figure that out, then I can just, like, pop into one of those other files, but just just there I can access, and I can

Speaker 0: just Yeah. Yeah. Yeah.

Speaker 1: I can make change, then I could read relevant, then my change is right there.

Speaker 0: Yeah. Interesting. Cool. Yeah. No.

That makes a lot of sense.

Speaker 1: And that has made our workflow so much less miserable.

Speaker 0: Oh, yeah. For sure. Some, some of these episodes have run a little bit longer, but I feel really, like, well equipped with knowledge I didn't have. Not not sure I'm gonna go running for a git sub module anytime soon, but I definitely understand them why I really, really didn't before. Given that we have come in a little under time, not that that is a problem at all, is there anything else you wanna talk about or share around Git submodules that viewers may find interesting?

Speaker 1: Oh, that's a good question. About Git submodules in particular, other Git stuff?

Speaker 0: Get get sub modules. Get stuff writ large. I feel pretty okay about. Even some more advanced workflows, I feel okay about. There was just this one area I carved out sub modules, which I have avoided like the plague because I've never had success working with them.

And I could never work it out either.

Speaker 1: So I got my take as an as an alias enjoyer within Git is that I think that there are certain ways that you can paper over the complex workflows to make it easier for people that haven't interacted with them too much. As someone that has a lot of good aliases, You can, for example, add some, you know, pre commit hooks and, you know, simple aliases that make it so that people who are contributing externally have a slightly easier time getting set up. For example, like, if I try to build, like, it would be fairly trivial in so for example, the project I mentioned very early on where I was like, it it failed because there were some missing files in the git sub module that I didn't know I had to initialize. I think it would be pretty trivial at the beginning of the build step to be like, did the files exist in this? Okay.

Fail.

Speaker 0: Yeah. Exactly.

Speaker 1: Like, or errors. Did you initialize the sub module? Yeah. Exactly. So I think that, like, as with many things, there's a lot of ways that you can, like, kind of get out ahead of the pitfalls of get sub modules to make it easier for people to interact with them if you're going to go that route.

I do think it's a valid choice. Like, despite having, like, lightly lightly food, get sub modules as as a choice within projects, I do think that, like, there are certain projects where, like, that is an adequate solution. I don't think that I'd go so far to say that it's perhaps the best solution. But like I said, there's, you know, plenty of projects that would be like a fine choice.

Speaker 0: Absolutely. Interesting. Cool. I think that might be bringing us to the end of our, of our learning session around git submodules. Anything else you want to share about you or projects you are working on?

Speaker 1: I don't I don't think so, to be honest.

Speaker 0: Fantastic. Easy easy segment that. Well, thank you so much, Shelley, for joining us on learning things I love to hate.

Speaker 1: Thank you for having me.

Speaker 0: No worries at all. And until next time, bye for now.