The Laravel Podcast

Matt Stauffer:

Welcome back to the Laravel Podcast, season four. Today, we're going to be talking about GIT with Gemma Anible. Stay tuned.

Matt Stauffer:

Welcome back to the Laravel Podcast, season four. I'm your host, Matt Stauffer. And I just want to give you a quick note before we get into this episode. Because it's the coronavirus and the pandemic, and everybody's working from home, our technological situations are a little bit different.

Matt Stauffer:

And today I ran into my first time with this happening, where Skype reset my audio settings when it had to restart to make a change apply, and I didn't notice it. So even though I checked my audio three times, or two times, or something, it reset the audio when I restarted after I'd done those checks. And so it ended up recording this entire thing, not from my beautiful Shure SM7B, as you can hear right now, but instead through the headset microphones, tinny, and small and echoey. So I apologize. The audio on my side is not going to be very good for this one, but the conversation is fantastic. I learned a ton. It was a really enjoyable time. So I hope you'll forgive me for my bad audio and enjoy listening to Gemma. Let's get to the episode.

Matt Stauffer:

Welcome back to Laravel Podcast, season four. If you have just tuned back in, or if you haven't been listening for a while, a reminder, every single podcast episode of this season, we're going to be talking about a different topic, starting from hopefully the beginning of what a new Laravel programmer would need to be thinking about and learning. And this is sometimes Laravel programmers who are programming other things, like JavaScript, and sometimes folks who are brand new or maybe old PHB heads. So it's kind of like a little mixture.

Matt Stauffer:

So today we're going to be talking about GIT, the best version control system I've ever experienced in my life. And I think that some of y'all might know GIT, some of y'all might not know GIT at all. Some of y'all might be sitting here wishing we were using Mercurial or whatever, but in general, first of all, it's always good to cover the basics, knowing GIT is one of those things that we all absolutely must do in order to do our jobs well.

Matt Stauffer:

But second of all, it's one of those things where I think we all use just a tiny little subset. So I have what I would consider ... she's not claiming this for herself ... but I would consider her a GIT expert, at least in my pool of people I know, she's one of the most expert level GIT users. How about we put it that way? So Gemma Anible, we met at Laracon EU four, five years ago, four years ago, I think, and you give a fantastic presentation about GIT, and I've connected with you a little bit online since then. And so I just wanted to bring you on to teach us a little bit about GIT, both in general and then also as it applies to a modern web application framework developer.

Matt Stauffer:

But before we get into that, can you just say hi and tell us a little bit about you?

Gemma Anible:

Yes. Thanks for having me on Matt. Hi everybody. I'm Gemma Anible. I am a software engineer, mostly PHP and Go. I work for Wonder Proxy, which is a proxy company and we've got a lot of proxy servers, all around the world. We help you with localization testing. It's cool.

Gemma Anible:

Yeah, that's me. I've been a developer for maybe 15, 20 years about ... yeah.

Matt Stauffer:

Nice. And so we are going to start at the very beginning. And remember I say this at the beginning of every episode, everyone, but the goal is both for this to be useful for someone who's brand new to it, but also keeps some things that are fun and interesting. So even if you're listening to this saying, "You know what, I've been using GIT for 20 years," I hope you still have something to learn.

Matt Stauffer:

But we're going to start with the simple stuff. So first question always is, if you were going to describe GIT to a five-year-old, how would you describe it?

Gemma Anible:

All right. So I had a couple of thoughts on this.

Matt Stauffer:

Okay.

Gemma Anible:

The first one was, imagine you're telling a story, and you're making up the story as you go. If you imagine that as you're Hansel and Gretel and the story is a forest that you're exploring, GIT is the breadcrumbs that you leave behind so that you can find your way back to other points in the story maybe you left behind and want to explore in a different direction, except nothing comes along to eat the breadcrumbs.

Matt Stauffer:

Great.

Gemma Anible:

Hansel and Gretel and the breadcrumbs is one option for that, and another one is to choose your own adventure story where ... All right, so I'm dating myself. When I was a kid, Choose Your Own Adventure stories were like super, super-popular. We had all of them out of the library. It was great. And I would always, whenever I did one, you always get to a decision point, a spot where like, "Oh, I don't know what to choose. I don't know. Well, I don't know," and you put a bookmark in it or you fold the page corner down or something, so that you can keep reading ahead, but you know, you can get back to that decision if you want to try something else.

Matt Stauffer:

Yeah.

Gemma Anible:

That's GIT.

Matt Stauffer:

That's brilliant. Wow. That's a really great ... And you feel like you're cheating a little bit by doing it, by putting that bookmark, you're like, "I'm not sure if this is the right decision."

Matt Stauffer:

So GIT is kind of cheating and gives us superpowers, basically.

Gemma Anible:

Yes, yes it does.

Matt Stauffer:

I love that.

Matt Stauffer:

Okay. So now let's roll it up a little bit, and assume that I have been writing PHP for 15 years and I have Index to Final. No, really this time.php, you know, along with Index 2 and Index 1.7 and Index 1 and Index whatever.

Matt Stauffer:

Could you give me a little bit of an idea? So, I'm potentially brighter than a five-year-old, I'm a grown human who potentially understands computer science and everything like that. How would you talk to me about what it is and what it provides to me as a programmer. Again, at the simplest level, but what is GIT to a programmer who doesn't understand version control?

Gemma Anible:

GIT is freedom to explore in your code, explore what you're writing, explore your creativity, try stuff out and collaborate on it and share it with other people and then decide that it's terrible. And go back to a state that was good, that you know it was good. And you can always get back there. So GIT is a tool to help you explore things faster. If you're doing indexbeta.php and index, okay, final.php and Final 2 and Final 3, it starts to get really unwieldy right around final3.PHP. I feel that's around the point when you're like, "Shoot, there was a thing. Oh, I was trying this thing in a different one and I don't remember which Final this was in, so now I just have to go look through all the files and see where this change was, where the heck was that."

Gemma Anible:

GIT actually tells you, it gives you the path that you trace to get to where you are now. And it lets you try other things in completely different directions and track that too, and then switch between them very, very easily and very quickly.

Gemma Anible:

This was actually one of the big things when I started programming, I used CVS for a very, very short period of time, but then I really cut my teeth on Subversion. So this was, you know, late '90s, early 2000s. Your Subversion is the new hotness in version control. Their mission statement was something like 'we're going to do four things better than CVS,' or something like that.

Gemma Anible:

And it was great, but there were some things about it that I found really confusing. Everything was a copy of a file. And if you wanted to do operations on branches, if you wanted to explore in a different direction, you had to have a whole other copy of all of your files in a different directory. And that was a 'branch' and stuff was really slow. Anyway, it was great for the time. It was revolutionary for the time, but the big thing with GIT that was so great, was like, wow, all of this is so much faster because it's just happening on my computer. It's just happening on my computer and I can share ... we'll get into this, I'm sure later ... but I can share it if I want to, but it's all happening. It's all right here. And I can just do whatever I want and then get back to it. So that that was the big thing with, with GIT when I learned it.

Matt Stauffer:

That's really interesting because I think your perspective as someone who's used Subversion and other tools like that, is going to be different than someone for whom GIT is the exact same word as version control.

Gemma Anible:

For sure.

Matt Stauffer:

And I think for a lot of people who are learning now, when you learn the value of GIT, you're also learning the value of version control. One thing that was really interesting is when I say. "What's so good about GIT," your answer was truthful to my question, and I realized that I had accidentally really intended to ask you, "What's so good about version control?"

Matt Stauffer:

And it's helpful to think that for a lot of us, they mean the same thing and they're not the same thing. And I've used Subversion as well. And for anybody who doesn't know, Subversion essentially hosted on somebody else's server and, like Gemma said, whereas with GIT, you're keeping your files and then each branch is basically understanding the changes that have happened to those core files. In Subversion, it's actually, as if you again, in the old world, you duplicated your entire application and renamed it to Application 2 and then Application 3, so it was version control.

Gemma Anible:

It was mixing tactics sugar around that. It was making that kind of nice ... Yeah, a different sort of workflow.

Matt Stauffer:

Yeah. So as, as we're talking about the values of GIT, note for those of you who maybe are only familiar with GIT, which is probably a lot of people, that's totally fine, that we're both going to be talking sometimes about version control and its values, and sometimes about GIT specifically, and these days, it's not to say that there aren't people who use some of those other tools, but the vast majority of context are going to be using GIT, so learning GIT and learning version control through your experience of learning GIT, I would definitely say is a really good start for most people.

Gemma Anible:

I agree, and that reminds me of this conversation I had, I think it was on Reddit, a few years ago where somebody was venting about how frustrating it was to use GIT, and all these merge conflicts are so annoying, and why does GIT make this happen? And it was that kind of a switch where the problems they were having, the things they were frustrated about, were a result of working on a team with other people on the same code, not a problem with GIT. GIT is something to help solve those problems. But the problems they were having were actually, this is just what it's like to work with people on code. You're going to have merge conflicts if you work on the same file. That's the way it goes.

Gemma Anible:

So that was a really interesting starting point for that person. It was a really interesting conversation for me, to just kind of see from that perspective. It was good.

Matt Stauffer:

GIT do seem to be frustrations because expect it to be so smart because it is, that when we hit that moment where it's not able to do everything, we're like, "Well, come on, I'm used to you magically reconciling these things and now you can't magically reconcile this thing. What gives, GIT?"

Matt Stauffer:

And so I think that definitely shows a little bit about how effective it is in taking that thinking off of our plates, that we're surprised when we have to do some of that thinking.

Gemma Anible:

Yeah, exactly.

Matt Stauffer:

I like that. Okay. So if somebody were to not understand. Let's presume that our primary target audience not only doesn't know GIT, but they also don't know other version control systems, which I think is going to be a broader target audience.

Matt Stauffer:

What are the most important concepts somebody should understand in order to be, let's say not proficient, but at least useful in GIT/using version control as a programmer?

Gemma Anible:

Sure. So as with all things, context matters here. It's going to depend a lot on the team you're working on. Are you even working on a team or are you by yourself? What is your team workflow look like? How do they use it?

Gemma Anible:

So there's a lot of hemming and hawing as far as what's important. I think one of the foundational concepts is just a diff. A diff. So, a diff is a way to represent differences between two files on a line by line basis. It's become a standard on Linux and now Mac environments. This is what it looks like when two text files differ, this is how we're going to represent it. And it's pluses and minuses on the left side.

Gemma Anible:

If you're a developer you've probably seen this, but that's one of the foundational things, because GIT is basically a bunch of diffs just strung together. If you can understand how a diff works, and you totally can, then you can imagine GIT as just stacking a lot of diffs on top of each other.

Matt Stauffer:

I love that.

Gemma Anible:

And individual commits is like, "I'm adding a new diff to all of the other diffs." And when you check out a different branch, "Okay, I'm undoing all of these diffs. And then I'm redoing the diffs in this other branch." And I'm gesturing with my hands, which podcast...

Matt Stauffer:

It's funny, because those gestures are actually really helpful, and I just thought in my head, "Oh man, I wish we did have video on these ones."

Gemma Anible:

Just imagine gesticulating wildly.

Matt Stauffer:

And I love how you said that because it's making me think of the fact that ... So first of all, there's a couple of pieces. One of them is let's imagine our Index, Index 1, Index 2, and index3.php.

Matt Stauffer:

Part of the problem with those is that it's hard for us ... there's lots of problems ... but one of them is it's hard for us to know what changed from one to the other. And second of all is if you're making changes, not just in PHP files, but very large files, like we were talking about Subversion, everything's going to get very slow and very unwieldy very quickly. So imagine instead of Index, Index 1, and index2.phb, instead had index.php, which is the state it was at the beginning, and then index1.diff, index2.diff, index3.diff, and the application was smart enough to know anytime I want index.php, I take the base PHP file, and then I apply the diffs. And the diff is just that the lines have changed between the two. So you can imagine it's much smaller, it's much faster. And it's so much easier to understand, because you're only seeing the thing that changed.

Matt Stauffer:

So first of all, thank you for that.

Gemma Anible:

No problem.

Matt Stauffer:

And second of all, that took me to two other ideas that interestingly I think are very prominent today for people who, if they seem very technical, but if you are familiar with either blockchain or event sourcing, you might be familiar with these ideas where basically it's a series of events that happen, and you can always get to where you are now by replaying all the things that led up.

Matt Stauffer:

And it's just the same kind of idea. You start with whatever index.php was at the beginning, and then just apply all the diffs until you get to where it is now.

Gemma Anible:

Yeah, exactly. All three of those GIT and blockchain and event sourcing is all sort of a description of history, and the state where you are right now is a sum of all the history of that came before. And you can get back to any spot you were before in history by just undoing what was done up to the point.

Matt Stauffer:

That's amazing. It's so funny, because I was so sure that you're going to say a commit is first and a branch second, and a repo is third, and those things do matter. And we should talk about those, but I really appreciate the way you say, "You got to have your mind in the right space before you can even start talking about those."

Gemma Anible:

Yeah. If you're learning GIT, there are so many resources online at this point for basics of GIT. Five commands you need to know to use GIT. You can Google that, no problem. And you don't have to be a developer to understand how to use those commands to be useful.

Gemma Anible:

But if you can wrap your head around what GIT is conceptually, it'll make it a lot easier when you run into problems later.

Matt Stauffer:

I love that. So, if you were at this point and you hear a GIT repo, or you hit a GIT branch or something like that, and it sounds unfamiliar, hit pause, and just go look up a tutorial about the basics of GIT, and it'll teach you about what branches and repos and commits are. Not everything, but just the really quick basics, and I love that.

Matt Stauffer:

There's so many things out there teaching you, if you can't find something, find anything by Atlassian. All of their teaching around GIT, I've really enjoyed. And we'll talk more about teaching resources. I'll ask you for a list of your favorites. Go do that and then hit on pause. And we're going to talk a little bit more about some of these.

Matt Stauffer:

So I'm going to do a little bit of a shift. Actually, hold on. No, you only said diff. Are there any other really important concepts you think that people should understand to be useful in GIT?

Gemma Anible:

Let me think. Okay. So again, coming at it, not from the perspective of what commands are important, but conceptually how it works, I feel like today, in particular, when we do collaborative editing on files with people, we're using Google docs or we're using Hackpad or we're using ... I don't know ... other collaborative. If we're writing a blog post in a hosted blog provider in some online editor and it's auto saving for us, GIT lets you do collaboration with other people, but it's not going to do that unless you tell it. So the changes you make to your pository on your local system stay local until you tell GIT, "Hey, share this with somebody." Subversion is not set up that way. Subversion, you make changes, you have to talk to the server to tell their pository that, "Hey, I made some changes," and then it's available to everybody.

Gemma Anible:

So that was a big shift with GIT, and it is different from how we do other collaboration on other sorts of files. So I feel like that's an important thing to understand. And another thing, this is a little more esoteric, but understanding the difference between on your local system, the GIT repository and your working directory, is big. So the GIT repository is the source for all that history. It's all that diff stacked on top of each other and GIT knows that, okay, at this point, at two o'clock yesterday, this is what their pository looked like. And at three o'clock you'd made some commits. So then it looked like this, and that's the repository, but your working directory is a working copy of what's in the GIT repository and you can do whatever you want in that working directory. But until you tell GIT on your local system that, "Hey, I'm making a change to the repository now," it's not going to know anything about the changes you made.

Gemma Anible:

So, if you make a whole bunch of really cool changes and write all your unit tests and this is ready to go and you log off for the night and you forget to commit, and then your hard drive dies-

Matt Stauffer:

It's gone.

Gemma Anible:

Oh, well, that's really sad for you. But yeah, so it's a much more intentional editing experience, developing experience, where you actually have to say, "Okay GIT, I made a change and I want to tell you about this now. And I want you to save it."

Matt Stauffer:

There's a couple of layers of that. So I'm going to push through them. Once again, I appreciate that. I'm really glad you're on this podcast because I love the way you think of these things.

Gemma Anible:

I could talk about GIT for hours.

Matt Stauffer:

That's why you're here.

Matt Stauffer:

So the first thing is, if we were to continue the event sourcing or the Bitcoin allegories or whatever the word would be for that, would it be right to say ... So in event sourcing, they often talk about a projection. So you've got a history of events that have happened, and if anyone's not familiar, in that world they're often talking about, you imagine a bank ledger. So your bank account starts with zero dollars, and every single time something happens, either adding money or taking away, that's tracking as event. And so at any given moment, if you want to know how much money is in your bank account, you basically just apply all the events that happened between zero at the beginning and to now, and then you know how much money you have, but often you don't want to run all of those calculations every time.

Matt Stauffer:

And so you make a cache of what the current moment is. And that's often called a projection or something like it, where it's basically like run through all the things and then store it in some particular form, that is the best way for us to understand what the result of applying all the previous events looks like. And so in the bank example, it would probably just be like a bank balance.

Matt Stauffer:

Is it safe to say that in the GIT world, your working directory is basically the projection of the history of your files, and basically if you were to run from the beginning and apply every single diff in the branch that you're in, until you get to the end, that is basically your working directory until you start making change. And as soon you start making changes, it's all those plus whatever changes. And you're building a new diff as you go, until you do a new commit.

Gemma Anible:

Yes. Yeah. So your working directory is the sum of all of the diffs that came before the commit that you have checked out. So whether that's master, or maybe that's some random commit that you just checked out, because you wanted, you're doing something crazy with GIT bisect, and you're having a good time and goodness knows where you are. It's the sum of all of the diffs up to the commit that you're in. So starting with the commit that you've checked out and going all the way back to the first commit and the repo.

Matt Stauffer:

Yeah. Okay. And so I want to get back to them a little bit later, because I think there's a little bit to talk about in terms of what's staged or not. But I think we're probably not quite there yet, but just to remind both of us to try and get there. Okay.

Matt Stauffer:

So you said there's multiple layers. I'm going to take a break for a sec, and remember you said so many good things and I wanted to talk on top of them. So the other layer on layer on layer I noticed there, was the idea of GIT as living on your local machine versus living on a server. And I think this is a perfect segue into our next question, which is about GIT and GIThub and whether GIT is centralized or distributed. And how do I have my repo on my local machine, but it's really hosted on GIThub.

Matt Stauffer:

And could you give a intro level both to maybe how GIT is intended to be, and how us primarily using centralized servers, like GIThub and GITlab is a little bit of a shift from that, and if there's anything that would be helpful for us to know as we live in that space.

Gemma Anible:

Yeah. So this is one of the cool things about GIT that I love. In the way that GIT is set up, setting aside, GIThub and GITlab and whatever you're using for your projects, Bitbucket, whatever, the way GIT is set up, there is no centralized server. There is no centralized server. There are lots of different repositories. There are lots of rep-

Gemma Anible:

... live server. There are lots of different repositories. There are lots of repositories all over. They might be on your computer, they might be on your teammate's computer, they might be on some sort of corporate computer that's a backup. They could be everywhere. GIT doesn't know that, "Oh, this repository, this is the important one, this is the canonical one." It has no idea.

Gemma Anible:

So GIT doesn't know what repositories are "important" to you. So all of the centralization that we have coalesced around because it's convenient, using things like GIThub and GITlab, that is a choice that we make. It's not a restriction of the tool. It's not like the truth says, "You must do it this way." And the reason that's cool is because you can... And I did this when I first started using GIT, we worked this way.

Gemma Anible:

We literally had repositories on people's machines, their workstations, that were acting as remote repositories for other team members. So we were pushing code back and forth directly to our teammates instead of going through a central server. And that's something that GIT is... That's what it's built for. That's really what's it's built for. In the olden days, they would mail sets of commits around as email attachments and then apply them in their local repositories and it was really wild.

Gemma Anible:

So, the centralization that we have with GIThub and GITlab is convenient, because a lot of us are distributed and it's nice to have a canonical. Everybody can use this as the source for cloning and I can have a repository on four machines and they're all going to point back at GIThub repo and that's great. But that is a choice that we have made, it's not a restriction in the tool.

Matt Stauffer:

Yeah, I think that's very helpful, because I think, because of how ubiquitous that choice is, I think it really seems a lot of folks' minds, almost like the subversion that we're talking about before, where there's a centralized server and everybody else just has dumb clones of it. And in some ways, yes, they are clones but in the functionality of GIT, my local on my machine is no more or less important than the GitHub one. Which is, I think, it's really helpful. Same story with me except a little different, before things like GitHub came out, I was worried about what happens, like it's great if I have all these commits, but what happens if my laptop hard drive tanks? The entire well-groomed history of my repo will have gone down with the rest of my thing.

Matt Stauffer:

And so, I had a server and I put a GIT instance on that server and I was like, "Oh, it's going to have to be like a super special one." No, it was the exact same GIT installation that I had on my local machine. The only difference was, I pushed up to it regularly, so it was my backup. And I was like, "Oh." And so then GIThub came out and in some ways, GIThub can feel like this really fancy thing and if you do the similar thing on your own server, you're doing a dumb version of GIThub. No, GIThub is just doing what I did, I had my own server where I installed GIT but with extra tooling and I don't have to run a server to use GIThub. So it's cool to think of it more like, GIThub is just a convenience layer on top of the ability for me to have as many repos as I want.

Gemma Anible:

Yes. That's a great way to put it. It's a convenience layer on top of GIT, that's perfect.

Matt Stauffer:

Yeah, that's awesome. Do you think that, there's any aspects of those types of services, GIThub, GITlab, GITbucket that they add, and I've got one in mind and I'll just say it, like pool requests? Or do you think that there's...

Gemma Anible:

Yep, that's what I was going to say.

Matt Stauffer:

Yep, I shouldn't have said it, I should it just give you a chance. But I want you to talk about...

Gemma Anible:

No, that's fine.

Matt Stauffer:

... Is there anything that you think, that they add that you're glad they've added? Or do you think there's anything that they either don't enable or maybe that people using them don't know about that maybe has been harmful to us as really being proficient GIT users?

Gemma Anible:

Oh, that's a good question. Okay, well let me go in order. So, I think the pull request system that they built is spectacular and it opens up collaboration to people who are not developers in a way that didn't exist before, as far as I know. I work with a project manager and she regularly comments on GitHub pull requests, on copy or commenting on whatever, because she can, because it's that easy for her. She's not a developer, but she can totally use this tool, you know?

Matt Stauffer:

Yeah.

Gemma Anible:

So it doesn't rely on programming knowledge or deep system administration knowledge or anything like that to use. As far as stuff that is taken away, GIT has a lot of functionality and that's its strength and its weakness I feel like, mostly because the UI can be very arcane and there's a lot of memorization involved or just every time you want to do something, you need to read the man page or whatever, because the order of arguments isn't always the same and its stuff isn't always spelled the same. GIT as infamous for this.

Gemma Anible:

But there is a lot of functionality there. And I do think that, in GIThub's path to democratizing collaboration on code, they do gloss over some of the cooler things you can do with GIT. And I think, as they keep building GitHub, they keep adding more and more things. Like you can merge a pull request as a rebase now I think?

Matt Stauffer:

Right, yep. You can choose merge or rebase.

Gemma Anible:

Which, is pretty cool.

Matt Stauffer:

Yeah.

Gemma Anible:

Yeah, and I did this for a long time. So I feel like, it does just smooth out some of the edges and in the process, some of the neat features. I think on the whole, net positive.

Matt Stauffer:

Yeah. And one of the cool things is, a lot of those neat features that you mentioned bisect before. But plenty of these other things, where when things have gone really South with a GIT repo, either we used or learned to use some of those really fancy, amazing tools that GIThub doesn't expose. But it doesn't matter, we just pull the repo down and use those tools on our local machines and then push it back up to GIThub. So it's cool that, it's not as if by choosing to host your stuff in GIThub or GITlab or whatever, you now can't use those tools. It's just not surfaced as quickly. I didn't expect this to be our next topic of conversation, but I'm just going to go there. What is your opinion about command line versus GUI for GIT?

Gemma Anible:

So, I don't really have an opinion. I am a hardcore command line user, I have a lot of little GIT aliases to make that easy for me and to give me nice visualizations of the history graph and whatnot. I haven't really found a GUI that I am as fast in and that's probably just because I haven't put in the work to learn the tool, which I have with command line GIT. But there are a lot of people who have put in the work to learn the GUI, for whatever GUI that is, whether it's... What is it, on Mac towers?

Matt Stauffer:

Tower and GIThub Desktop.

Gemma Anible:

Yeah, GIThub Desktop. There used to be one, oh I don't know if this still exists, called TortoiseGIT.

Matt Stauffer:

We'll have to put it in the show notes, if it still exists. I never used TortoiseGIT, no.

Gemma Anible:

So there was originally TortoiseSVN.

Matt Stauffer:

Yeah, that I know about.

Gemma Anible:

That was for Windows. This is for Windows and then, there was when GIT became a thing, they created TortoiseGIT. And it was basically the same interface, but for integrate. It was great. I'm sure you've got lots of Windows users among your audience, so that will be...

Matt Stauffer:

Yes actually. That's actually going to be huge.

Gemma Anible:

Oh really?

Matt Stauffer:

Yeah. So, what's interesting is that, just for your information, for all of y'all not just for Gemma, the folks who tend to be writing stuff and more prominent in a lot of our community are primarily Mac users because that seems to be the case. Mac and Linux users. But the people who are learning, there's a huge, absolutely huge contingent of Windows users, to the point where I feel like I need to take the responsibility to go buy a Windows machine and get really good at it, because I get so many requests for, "Can you rewrite this article for Windows? Can you update this page in your book for windows?" You might be surprised just how many Windows users we have.

Gemma Anible:

All right. Well, I'm still on Windows and Linux for development, but Windows the rest of the time. So I'm in that contingent. What was I even saying?

Matt Stauffer:

GUIs

Gemma Anible:

About using GUIs. And I work with people who have invested a lot of time in learning the tool that they decided to use and they're really fast with it and it makes them really productive. So for those people, awesome. Carry on, continue to be cool.

Matt Stauffer:

Use what works for you.

Gemma Anible:

Use what works for you, 100%.

Matt Stauffer:

And I would say... Oh, go ahead.

Gemma Anible:

Oh, well, I was just going to say, I think there is value in investigating some of the command line stuff, just because some of the more weird features aren't always surfaced in a GUI, because just like GIThub, a GUI is a convenience layer on top of GIT. So there's some value in seeing what's under the hood, but generally speaking, use what makes you productive.

Matt Stauffer:

Yeah, I love that. And I think a really good note there is, Gemma's answer for what works for her, and might for me as well, are based on the fact that, when we got started, it was a different world than it is today. And so I would say, if I were starting my friend's coding right now... Not if, I frequently do, ... and I'd get them on a GUI.

Matt Stauffer:

And it's the same thing, get productive and get fast because learning a GUI is a lot faster than learning a command line. Because, that's just going to be the way it ends up being. So then I tell them, down the road, I think it'd be really good for you to understand what these commands are doing. And some of the best GUIs actually show you a terminal log. And so when you click something in the UI, it actually shows you what it did. I think that's great. But I would say that, if you're asking today, how to start and someone tells you, "Start in the terminal," they might be well-intentioned, because they want to ensure that you learn the native stuff, but they might also just be gatekeeping a little bit. So I would definitely encourage you to just go find the best GUI for you, at least to start for new folks. Gemma to you.

Gemma Anible:

Yeah. Or try both. Try it in the terminal.

Matt Stauffer:

Sure, yeah.

Gemma Anible:

What makes it clicks for you.

Matt Stauffer:

You know, your answer is way better. It's not use the GUI, it's use whatever works for you. Don't let somebody else tell you what to use.

Gemma Anible:

100%. There is absolutely no right answer, as far as how you're using GIT.

Matt Stauffer:

I love that.

Gemma Anible:

Yeah, no wrong answer. There's a right answer, there's no wrong answer.

Matt Stauffer:

Well, no, but there's no right answer either, right?

Gemma Anible:

Right.

Matt Stauffer:

There's no canonically right answer. It's a conditional answer. It depends, trademark.

Gemma Anible:

Excellent, we got there in the end.

Matt Stauffer:

Yes. So we could geek out on that forever, but I'm going to move on to our next section. And I want to talk a little bit about... We're going to do real quick on a couple of common use cases and then move into some Common Challenges and Gotchas. So, we've already talked a lot about the primary use people have for GIT, but I did want to poke in a little bit about the fact that, when you described GIT earlier, you were often talking about exploration and you weren't talking as much about things that I think people might talk about boringly in terms of backing up your code or triggering auto deploys or sharing code between people. And obviously, GIT does those things, but you talked about something that I think it's less frequently talked about.

Matt Stauffer:

So, when you think about what people use GIT for and how they think about GIT, how they're regard it versus how they could, are there any things that you wish that people were more thinking about GIT as a tool for, that they maybe don't take advantage of what it provides them?

Gemma Anible:

I think, GIT is a fantastic tool anytime you're editing text. So that's not just developers, that's are you writing a book? Are you writing an article? Are you writing some sort of essay? Are you designing an experiment? Are you writing legislation?

Gemma Anible:

GIT is just a really good tool to manage the history... If you're interested in seeing how you got to a particular point, with whatever you're writing. If you're interested in tracing your steps backwards or in a different direction, with what you're writing, GIT is a fantastic tool for that. And it doesn't have to just be code.

Matt Stauffer:

Yeah. And I wrote my book in AsciiDoc, in GIT, because that's what O'Reilly uses, and I was not prepared for how amazingly helpful it was. And we use branches and I've got a guy who's been helping me research stuff now and he pool requests his modifications against my branch.

Gemma Anible:

Oh, that's so cool.

Matt Stauffer:

Yeah, he pool requests simpler versions, it just says, "Hey, edit this here." And so what I do is, I just look at the GIT Diff and every single place he put one of those, I go in, in my new commit and I replace his, "Hey, write something here," with my writing. So I can see where he put the notes and then I can see all this together in one place. And he and I can have conversations in the pool request notes in GITlab, and then we eventually merge it into master. And that's like deploying this latest edit to the book. And it's a fascinating experience, not code at all. And It's so cool.

Gemma Anible:

Yeah, no code. I actually looked this up, because I thought this was such a good question. Washington DC, actually the canonical version of the Washington DC legal code is in GIT.

Matt Stauffer:

Is it really? Because I've heard of people tracking code as geeks after a law is actually passed. But their actual canonical uses that?

Gemma Anible:

Yeah. No, this is actually legit. It is in GIT.

Matt Stauffer:

Wow, that is fascinating.

Gemma Anible:

I'll give you the link. I was amazed. I couldn't believe it. But GIT is perfect for that. And it was so cool. I was browsing the repo and it was like, they had just instituted something for... Am I allowed to talk about the pandemic or is this a pandemic-free zone?

Matt Stauffer:

Yeah. No, go for it.

Gemma Anible:

They just instituted some sort of... Something earlier than 90 days something for the pandemic and you could see there was a commit for it. It's like this is the coolest. Why do we not do this with all of our legislation? This is amazing.

Matt Stauffer:

And I was thinking, they could roll back that commit in 90 days but I guess that's not how it works. But still, it's an interesting idea.

Gemma Anible:

But they could do GIT revert and then edit it at the same time and make sure it never...

Matt Stauffer:

That's true, good point. This is cool. GIT is in a lot of places and I hadn't thought about the laws. I've seen that, but I didn't think about it. That's really fascinating. Okay, I think that I'm going to jump forward even though I don't want to, because I want to make sure we have enough time for the stuff at the end. So the next section for us is, "Common Challenges and Gotchas." So the first thing I'm going to ask you is, what are some times that you personally, have gotten tripped up by GIT?

Gemma Anible:

So, a classic one is... You know what? This is not embarrassing, I'm choosing not to be embarrassed by this because it's a good thing and it's fine.

Matt Stauffer:

We're all human.

Gemma Anible:

I constantly forget which direction merge happens.

Matt Stauffer:

I do it literally every time still after a decade.

Gemma Anible:

Every time. Okay, which branch am I supposed to have checked out and then merge the thing into the other thing. Every time. And, when you start doing weird things with merges, you get into doing different things with the ours copy and the their's copy.

Matt Stauffer:

Yeah. Which one's ours and which one's theirs?

Gemma Anible:

I can't keep that straight to save my life. I literally have to read the man page every time, usually a couple of times to be like, "Okay, so ours is this one on the left, then that's on the... Okay, wait, is that right?" Every time.

Matt Stauffer:

I will Google an example every time, because in the example they'll use like, "Ours is the feature," and I'm like, "Oh, now I get it." Literally every time. So yeah, I'm with you.

Gemma Anible:

Yep.

Matt Stauffer:

We haven't talked about rebase real quick. I'm going to describe rebase and you're going to tell me the ways I'm wrong.

Gemma Anible:

Seems unlikely.

Matt Stauffer:

Okay, so rebase takes the other branch that you're working with and... I always get this mixed up too, ... but it takes two branches and basically replays the diff to the commits of one branch on top of the other ones, so they sort of end up being interwoven, but they're not interwoven. Merge applies them at the end and rebase applies them at the time that they happen in my branch right? You know, I think you can do a better description here.

Gemma Anible:

No. That's great. That's exactly what it is. Rebase, just like you said, replays the diffs from one branch onto some other starting point, whether that's a branch or some other random commit or whatever. Let's just do some pseudo concrete examples. So you've got your master branch and you got your feature branch, at some point feature branched off of master. So you've got the starting point for the feature branch, that's where a feature branches off.

Gemma Anible:

If want to rebase the feature branch on top of the master branch, you're basically redefining the start point for the branch.

Matt Stauffer:

Right.

Gemma Anible:

Again, I'm gesturing, which is unhelpful. But it's a way to conceptually merge changes from master into the feature branch without actually doing a separate merge commit.

Matt Stauffer:

Right. So if we were to merge, so let's say, the goal we're doing right now is, our feature branch has been running for so long that there's new... Actually, this happened in Lambeau in a stream last week. I was working on a feature branch that had been running for so long, that it was on an outdated version of Laravel. And so I said, "Oh man, I really want an updated version of Laravel," and somebody in the stream said, "Oh yeah, I upgraded on master."

Matt Stauffer:

So I wanted to pool the changes, the commits that had happened on master into my branch. So I had two options, I could either merge it in or I could rebase it in. So, merging it in would have taken all of the updated stuff and then applied a single commit with all the changes to my repo or my branch and my branch would have stayed exactly the same, same history with this new one commit at the end that says, "Merge from master."

Matt Stauffer:

The benefit of that being, we're not tampering with history, the downside of that being we now have this ugly, basically merge commit. If I were to rebase it, what would have happened was, it would have taken, let's say there's 10 commits on masters since I branched off my feature, it would've taken those 10 commits and it would have applied them. And this is the thing I always mix up a little bit, it would apply them at the appropriate moment in time in my branch, or would it have taken all of them and then replayed my branch as commits after the last one?

Gemma Anible:

Closer to the second thing. So you've got your extra 10 commits in the master branch and you've got your feature branch, which is on an outdated version. If you're rebasing the feature branch, you are taking the commits in the feature branch and adding them to the end of the master branch. So the master doesn't actually change at all. The master tips, what master is stays the same, none of those commits are changing at all. The feature branch, you're basically duplicating all of the commits in the feature branch on top of-

Matt Stauffer:

I wish you had explained this to me five years ago. So, let me tell it again your way and then see if I'm getting it right. So let's say, my feature branch has had five commits since I branched and the master branch has had 10 commits. So, what rebasing would be, is saying basically you imagine those five commits, those are five diffs that are added to a single base commit and master. And when I rebase my feature branch, it's taking those five commits like severing the cord metaphorically, that attaches them to that one commit, 10 commits ago and instead moves them forward, so those five commits are now being applied against the head of master.

Gemma Anible:

Exactly.

Matt Stauffer:

That's awesome. So that, actually helps me a lot. Because I was going to tell you, one of the most common ways that trips me up, is when I'm trying to do a rebase and then it sticks me into this conflict resolution mode. And so, if you've never run into this before, you try to do a rebase and most rebases just happen magically. But sometimes, it says, "We have something we can't resolve in applying this one commit." And the problem is, I never knew it well enough, how to handle resolving to change that commit without breaking the history and master, because I thought they were interweaving. And now what I know is, they're not interweaving at all. It's just helping me say, "Hey, master is what it is, we're now moving the state of your five commits and those commits are going to have to be a little different, in order to not break basically when we apply them here."

Gemma Anible:

Exactly.

Matt Stauffer:

So, I could change whatever the heck I want in that commit, because all I'm changing is my feature commits, not master.

Gemma Anible:

Yes.

Matt Stauffer:

I have needed this moment for so long. If anybody doesn't understand what I just described, hit me up on Twitter and I'll draw a diagram for you. And I could probably actually recreate it, because almost every time I rebase this happens. Oh, that's magical. Okay. That's awesome. I know y'all tuned in to learn things.

Gemma Anible:

I rebase constantly, I'm a huge rebaser. I'm a huge fan of rebasing.

Matt Stauffer:

Okay. Well, so if anybody needs to know more about rebasing, hit Gemma up at G-E-M-M-A-L-Y-N-N on... No you're ellotheth aren't you?

Gemma Anible:

Yes, I'm ellotheth on Twitter. I think there is a Gemmalynn and it's not me.

Matt Stauffer:

Yeah, she's like a newspaper reporter or a news caster or something.

Gemma Anible:

Yeah, possibly. There's a lot of them. It was a really popular name in the early '80's. There's all these British women walking around with my name.

Matt Stauffer:

Interesting. Was there like a TV show or a movie caster?

Gemma Anible:

Yes. So it was called, "Solo." It was Felicity Kendal.

Matt Stauffer:

I've never heard of it.

Gemma Anible:

She played with my name Gemma.

Matt Stauffer:

That's awesome.

Gemma Anible:

It's amazing. If you ever get a chance to watch it, it's great and parents like it.

Matt Stauffer:

It's going to go in the show notes as well, everybody. And we all got to make sure we watch it.

Gemma Anible:

We all need more of Felicity Kendal in our lives.

Matt Stauffer:

I also have no idea who that is. I'm actually going to go look it up to see if I know who she is. Felicity Kendal. But @E-L-L-O-T-H-E-T-H, right?

Gemma Anible:

Yep, that's me.

Matt Stauffer:

Let me see if Felicity Kendal is an actor in anything I have ever seen before. She's in, The Good... You can tell how old the movie is, by the movie cover. Those are definitely '60's and '70's movie covers.

Gemma Anible:

Yes.

Matt Stauffer:

Sixties and '70s movie covers.

Gemma Anible:

Yes.

Matt Stauffer:

She's doing acting right now.

Gemma Anible:

I saw her on the stage in London a couple years ago and she was effervescent. She was just unbelievable. She was just-

Matt Stauffer:

That is it. That is the word of the day. Did you get a chance to meet her afterwards and say, "I'm named after your character"?

Gemma Anible:

I did not. I think I had the opportunity to try to get in line and I was just like, no, that's silly, Gemma. Go home. And it was like what's wrong with you. Stand in line, what's the matter with you, Gemma, oh, my gosh!

Matt Stauffer:

Next time you should do it. Yeah, next time do it. That would be a story you remember the rest of your life, right?

Gemma Anible:

Yeah, right.

Matt Stauffer:

When I met my namesake-ish. All right. You explained one of your definitely not embarrassing common things. I explained one of mine that I have been doing wrong up until this moment. So everybody, if there's any shame, I got it.

Matt Stauffer:

What are some other common challenges you see people run into as they're learning and using GIT?

Gemma Anible:

Well, a really big and classic one that's all over Stack Overflow is oh, shoot. I made a mistake. How do I undo this? The difficulty with that is that there are a lot of different answers to that question. There are lot of different ways to solve that problem so it always turns into okay, well, tell me your life story and then we can figure out how to-

Matt Stauffer:

Let's go back a few tips to figure this out. What happened?

Gemma Anible:

Exactly. Exactly. Yeah. That's a really big one. One of the other fundamental ... I should have said this before ... one of the other foundational concepts with GIT is a commit is immutable. A commit doesn't change, ever. I'm going to put a small asterisk there because you're going to have some listeners who know a lot about GIT internals and they're going to be like, no, no, no. You can totally change a GIT commit. Yes, fine.

Gemma Anible:

Normal people ... makes it hard-

Matt Stauffer:

It's immutable for most of us.

Gemma Anible:

Yes. It's immutable for most of us unless you start literally going into the .GIT directory and messing around with the actual files themselves.

Matt Stauffer:

Don't do that.

Gemma Anible:

We're not doing that. Yeah.

Gemma Anible:

That frees you up a lot. That's really cool and that's part of why you can always get back to where you were in GIT, but it's also not immediately obvious, especially when you have commands like GIT commit to --amend, which makes it sound like you're changing something.

Matt Stauffer:

Yeah. Change the existing commit and fix that typo in the commit message.

Gemma Anible:

Yeah, exactly. Yeah. So-

Matt Stauffer:

So what really happens? Oh, good. You start.

Gemma Anible:

Well, no. What's really happening there is GIT is duplicating that commit for you with the fixed commit message, but if you had already pushed that commit, you pushed the original and then you "changed it" which was really creating a new commit. Now when you try to push that again, GIT's going to be like, 'What are you doing? You already gave me this history. I don't know what you want me to do with this.'

Gemma Anible:

I don't know if this is still the case, but for a while it would try to give you helpful advice and be like, 'I can't push this because there's already stuff up there. Why don't you do a GIT pull-'

Matt Stauffer:

Really?

Gemma Anible:

'And fix that.' Yeah. Why don't you just do a GIT pull to get-

Matt Stauffer:

Huh. I don't think it does that now, but I hope it doesn't, because that's a terrible idea.

Gemma Anible:

Well yeah, exactly.

Matt Stauffer:

In this case.

Gemma Anible:*

And so people wouldn't know what to do because it's telling you to pull. So you do a pull and now you've got duplicate commits. Now you've got two commits that are the same in your branch. And you're like, what am I supposed to do with this?

Gemma Anible:

I think that does trip people up. Just the fact that commits are immutable and it's not always immediately obvious when you're not actually changing something; you're making a new thing that looks a lot like the old thing.

Matt Stauffer:

Yeah. For example, the rebase we're talking about. I said you're ideologically or whatever, metaphorically chopping those five commits off and applying, but you're actually duplicating those five commits and taking the duplicates and putting them-

Gemma Anible:

Yeah.

Matt Stauffer:

Yeah.

Gemma Anible:

Yeah.

Matt Stauffer:

Let's go there for a little bit because force push and all that kind of stuff, I think there's a good conversation to be had with that.

Matt Stauffer:

There are two primary circumstances where I see people at odds with each other in terms of how to treat certain things like commit messages, squashing, force pushes and whether you're allowed to edit your commits after you pushed them up to your central repo.

Matt Stauffer:

Let's start with I am the only person developing my project, and there's no auto deploys to a server. Is there any rules whatsoever about not doing duplication or is like hey, you know what, my local machine is the primary, so if I want to force override GIThub all day long it's no big deal, right?

Gemma Anible:

That's what I do, honestly. If it's just me and the stuff's not getting auto deployed anywhere and nobody else is collaborating on this, I will force push master for days, like all over.

Matt Stauffer:

Yeah. Can you tell us, for those of us uninitiated, what is force push?

Gemma Anible:

Force push ... we talked about how GIT is local and that's really cool and it doesn't know anything about other servers, other repositories, copies of your repository unless you tell it. Push is one of the ways you tell it hey, copy my stuff to this other remote repository that's on a different machine someplace; probably GIThub, but maybe it's your teammate's workstation, who knows?

Gemma Anible:

GIT has some built-in business logic that when you do a push to another repository, the repository that's receiving that push does some checks on what you're sending it. If the history doesn't make sense it'll be like, no, I can't. I don't know what to do with this.

Gemma Anible:

For example, if you ... let's just say you're working on GIThub and your teammate did a bunch of commits to master and pushed them up last night. You get in in the morning, and you don't pull it down because you haven't had your coffee yet and that's really sad for you. So you just start working away and you're committing to master and you're committing to master.

Gemma Anible:

Then you go to push it. The remote repository's going to be like, no, no, no, no, no. I already have. Okay, I can see where this diveres, I can see that you guys have similar history, but I have all these other commits from your teammate, so I can't take your commits right now because I already have these other ones; you need to resolve this.

Gemma Anible:

The resolution there is pull the new commits down into your repository, merge or rebase your stuff, and then push that back up. That makes the history smooth.

Gemma Anible:

So a force push is ... it's literally what the command is on the command line. It's like GIT push--force.

Matt Stauffer:

Force. Yeah.

Gemma Anible:

Or -- if you're lazy. Force push would say ... if you had pushed with that force option, GIT would have been like, ah! This is a force push, okay. I am going to discard your teammate's work and I'm just going to take your commits. Your teammate's commits are now gone ... well, "gone". Tactically you can still get back to them ... but your teammate's commits are gone; your commits are now master. Yeah.

Matt Stauffer:

Yep. Which is probably not what anybody intended.

Gemma Anible:

Right. Sometimes ... this is where you get into a lot of team process dynamics that exist over on top of the technical considerations. A lot of people have rules like you don't ever force push master. If you're working on a feature branch, you can force push that. That's fine, go for it.

Gemma Anible:

Like my team at WonderProxy, where it's a very small team. It's usually just two, at the most, three, people working on the same code base at a given time. Usually we're all working on different things and we may all have feature branches, so this is a branch that's just dedicated to changes for a particular thing that we're working on.

Gemma Anible:

Usually it's just one of us working at a time and we'll totally force push that, rebase force push, rebase force push all the time. That's pretty normal and pretty easy as far as our work flow because we're not overriding other people's stuff. It gets trickier when you've got multiple people working on the same code, the same feature.

Matt Stauffer:

The same branch or whatever, yeah.

Gemma Anible:

The same branch, exactly. That's where you need to communicate, because sometimes you are going to want to force push something. Sometimes you've got a really embarrassing typo and you really don't want it in that commit message. That's going to happen. You just got to tell people, you got to be like, "I'm force pushing this up. Get your stuff down and then you can rebase on top of it. Sorry." Just give them a heads up.

Matt Stauffer:

If my teammates and I were working in the same branch and they had the force push and I say okay, I've got all my stuff saved, what does the process look like of replacing my local? What's force pull on a branch?

Gemma Anible:

You can do just a regular pull and GIT will automatically merge for you.

Matt Stauffer:

Really? I thought it wouldn't. Huh.

Gemma Anible:

Yes. It'll do like a ... no, it'll give you a little merge commit. That's how, with the commit amending, that's how you end up with two commits that are the same because GIT will automatically do that. That's actually what pull ... pull is a combination of fetch.

Matt Stauffer:

Fetch, yeah.

Gemma Anible:

Yeah. Fetch is just kind of updating the-

Matt Stauffer:

The metadata, right? Basically?

Gemma Anible:

Yeah, that's what I was going to say. You're basically updating the metadata of okay, here's what the remote looks like. Here's what this remote repository looks like right now. So pull is a fetch and then a merge. Most of the time, that merge is a fast forward merge so there's not actually a merge commit, you're just advancing the branch pointer, and that may be a little ...

Matt Stauffer:

Oh. If I'm following the GIThub command line instructions and it says follow these instructions to check out this branch to your local ... because if anyone doesn't know, if you're doing a pull request, reviewing a pull request on GITHub, it says you can either click the merge button or pull down this work using GIThub Desktop or pull down this work using your command line. If you do command line, it gives you instructions on how to pull the work locally, make whatever changes you want and then merge the work into your master.

Matt Stauffer:

One of the things it says, GIT merge--no-ff, which I know means no fast forward. But, what's the practical reason why it's saying no fast forward? What does that mean in that line of code?

Gemma Anible:

You do a --no-ff. You do a no fast forward merge when you definitely want the merge commit. I actually do this a lot.

Gemma Anible:

My most common work flow with GIT is I'll have a feature branch, I'll be rebasing that feature branch on top of master on a very regular basis. When I'm ready to deploy ... well, when I'm ready to merge to master, which deploys ... I will do a no fast forward merge so that I get a merge commit that gives me my feature branch on one side and then just a straight line from the merge commit to the previous tip of master on the other side. It's really obvious that oh, hey, there was a branch here.

Matt Stauffer:

Yeah, that makes sense.

Gemma Anible:

This is the work for a particular feature, and then here's the merge where we deployed. Then we keep going from there.

Gemma Anible:

The other option is to do a regular ... well, default ... fast forward merge, which is just GIT looks at it. When you're merging two branches and the ... we'll go back to the master and the feature branch. If you've rebased your feature branch on top of master, you're thinking of it as a branch, but it's a straight line from your feature all the way down to master and beyond. There's no other merges in there.

Gemma Anible:

A fast forward merge just says oh, we don't actually have to merge anything. There's no diverging commits on master so we're just going to say that your feature branch is now master. And then we go.

Matt Stauffer:

Interesting. Okay. Huh. There's so many forks I could go for from here, but there's one I want to clarify. When you say you rebased your feature branch on top of master, what that often makes me think in my mind is we're making changes to master. Just a clarification for everybody: If someone says "Rebase your feature branch on top of master" the changes are being made to your feature branch even though it sounds the opposite, just because of how the operation's happening?

Gemma Anible:

Yes. Exactly. Master is not changing. You think of master as a ... my goodness. Okay, the first analogy that came to mind is pretty silly, but think of master as a tree that only has a couple of actual branches. An actual tree with actual little skinny branches. This is like a six year old, I don't know, oak or something and it doesn't have very many branches.

Gemma Anible:

And you literally chop off a branch and then glue it to literally the top of the tree. The tree, the top hasn't-

Matt Stauffer:

Right. So you put it on top of ...

Gemma Anible:

Exactly.

Matt Stauffer:

Right. The tree didn't change and you moved it, so you changed the state of that branch; you didn't change the state of the tree. Even though it's the branch that's changing, the way to describe it is we put that branch on top of the tree.

Gemma Anible:

Yes.

Matt Stauffer:

Okay. I like it.

Gemma Anible:

Yeah. Part of how I think of this ... I feel like everybody has a different epiphany with GIT at some point. If you haven't had an epiphany with GIT you'll have one eventually, trust me.

Matt Stauffer:

It might happen during this podcast, because I think I may have had at least one already.

Gemma Anible:

I know. The explanations are just getting weirder and weirder at this point. But my big epiphany with GIT was oh, my goodness, it's a graph. Oh, my goodness, this is a GRAPH. There's circles connected by lines, and the circles are the commits and the lines are like the knowledge of the previous commit. It's a graph. That has colored everything about how I interact with GIT, including-

Matt Stauffer:

Yeah. You studied computer science, then, I assume?

Gemma Anible:

I haven't taken a computer science course. I have a software engineering degree, but a graduate degree, so you know, the actual practical skills were left to the plebs and we did things like project management and cost estimation metrics.

Matt Stauffer:

Got it. Sorry I interrupted you. You said including what-

Gemma Anible:

No, no, that's fine. When I say things like I rebased the branch on top of master, I'm literally envisioning in my head, branches on a graph and one of them moving to a different spot. Yeah. The graph thought pattern just infects everything and it infects how I think about GIT and how I explain GIT, which doesn't always work for people who don't think about GIT that way.

Matt Stauffer:

Or when you are on a podcast and you can't use your hands to ... because I'm getting the show of all the hand movements and everything you're-

Gemma Anible:

Oh, my gosh. Continuing to just...it's happening. It's all happening.

Matt Stauffer:

No, it's totally fine. I will actually link to ... because there's a few people who have actually shown graphics of GIT as a graph.

Gemma Anible:

Yeah, yeah, yeah!

Matt Stauffer:

I'm going to try and throw one of those in the show notes. That leads me to one more thing and then I think I'm going to have to stop branching and go back to the actual planned conversation.

Matt Stauffer:

One of the things I will often see in diagrams is arrows that are pointing the opposite way of what you expect. Could you explain-

Gemma Anible:

Yes! Is that confusing?

Matt Stauffer:

Yes. Can you explain to somebody why people do that?

Gemma Anible:

Yes. They're pointing in the direction of this commit knows about the thing it's pointing to. It'll be pointing backwards in time because the commit that you have checked out right now knows about the previous commit. That's it. It doesn't know anything about the next commit. It knows nothing about the next commit, it only knows about the previous commit, that's why those arrows point backwards and the file's confusing.

Matt Stauffer:

A mental model that helped me, an epiphany I had at the beginning of this is that ... would it be safe to say it's also those arrows are the direction that the diffs are being applied? Each commit is a diff added, applied to a previous commit, right?

Gemma Anible:

Yeah.

Matt Stauffer:

So if you imagine those as like diff arrows and every time you apply a diff to a file, it's basically one of those arrows being enacted, right? The most recent commit is a diff on the commit before it.

Gemma Anible:

The pre-commit, yeah. You could say this is ... oh, my goodness, I'm continuing to gesticulate, I'm sorry ... yeah, the commit you're on is a diff applied to the previous commit. So yeah, if you think of the line with the arrow as this is the diff that I'm applying myself to; yes.

Matt Stauffer:

Okay. If you imagine that arrows imply movement, then if you were to actually allow all of the circles that you imagine as being like commits to actually follow the movement of their things, eventually you just get a pile of those commits all on top of each other. If you squash that pile, then just the resolution of the initial state with all the diffs applied, at the end you end up getting basically your working copy.

Gemma Anible:

Yeah. Exactly.

Matt Stauffer:

Okay. That makes sense. So many more things to geek about, but I need to get to the remainder of this because we're going long. So remaining questions are going to be are there any tips or tricks or superpowers, is there anything else you want to talk about, where do we learn, and then my personal fun moment which I have been hiding from you this whole time so you don't know what it is.

Gemma Anible:

Out here.

Matt Stauffer:

Tips, tricks and superpowers. You had mentioned a few things that you think can be really helpful at times, that maybe don't necessarily get exposed all the time. Are there any tools or features to get that you just really wish that people, maybe to go like 201, next level, the GIT that they really should learn about?

Gemma Anible:

Yeah. There's a couple. If you're using command line GIT alias ... if you are familiar with the command line in Mac or Linux, you'll already be familiar with this, possibly. You can give yourself shortcuts. That can be as simple as making CO mean check out. It can also do really cool things like you can actually run little bash functions, little shell functions inside an alias and that can do things. The possibilities are limitless at that point.

Gemma Anible:

You can figure out what was the merge base for this, between these two branches or I want to not only fetch and merge, I also want to update these other things, these other branch pointers at the same time. You can really go nuts with this. Alias is a big one.

Gemma Anible:

Bisect, I mentioned once and that's like a whole other podcast.

Matt Stauffer:

It is. It's magical, though.

Gemma Anible:

It is magical! If you don't know what bisect is, go look it up, because it is so, so cool if you're trying to find where something broke, like where a bug started. It's a game changer, it's a game changer. If you're like none of this code makes sense, I don't know where this happened, bisect will help you.

Gemma Anible:

Another one that's a little more recent is patch mode is available in a whole bunch of commands now that it wasn't always available in.

Matt Stauffer:

I don't even know what that is at all.

Gemma Anible:

Okay, this is cool. Check out add and commit and ... feel like there's more. I think there's more, but we'll talk about those. They all have a mode where it can be interactive. If you're committing a file you can add a -p ... again, this is command line, but I'm sure this is available in GUIs as well ... you can add a -p and then it'll walk you through every single discreet diff that you want to add and you can decide yes, add this; no, don't add this; I want to change this on the fly as you're doing the command.

Gemma Anible:

That's fantastic if you care about how clean your history is because it lets you very easily split up a bunch of changes that you've made in your working copy and make them a nice, logical sequence of commits.

Matt Stauffer:

I've heard of that as -p. I never knew that was what it stood for. Just for those who are not familiar ... if you've ever seen me stream or anything like that, in GIThub Desktop it allows you to look at all the changes that you have staged and uncheck or check certain pieces of the file so that you can say wow, I did a whole bunch of work and I really should separate them out into different commits. That's GIThub's GUI basically giving you the ability to use patch mode, but you can do it on the command line as well using -p. Brilliant. I love it.

Gemma Anible:

Yeah. It's very cool. Another one is ... I've only got a couple more of these. One is -v for commit. This again, if you're using GIT GUI, this is already part of your work flow. But if you're in command line GIT, -v will load the entire diff underneath the commit message when you're committing.

Matt Stauffer:

Really?

Gemma Anible:

Yeah. So you can scroll through it just to do a quick sanity check as you're doing the commit, which is really nice.

Matt Stauffer:

That's brilliant. It does that in Vim, too?

Gemma Anible:

Yeah.

Matt Stauffer:

Oh, my god. I've got to go ... I'll try this later-

Gemma Anible:

Yeah. And if you're in Vim, it'll syntax highlight it for you.

Matt Stauffer:

Oh, my god, that's amazing.

Gemma Anible:

Yeah. It's great.

Matt Stauffer:

Okay, -v; I'm sold.

Gemma Anible:

Yeah. Another one that I use often is the --abort for merging and rebasing.

Matt Stauffer:

Rebasing, yeah. That's a familiar one.

Gemma Anible:

Yes. If you end up in some sort of a recursive loop of hell merging and rebasing, you can just do merge abort and you'll go back to wherever you were before and you can start over, and I do that a lot, because I have.

Matt Stauffer:

Yep. I wish I wasn't so familiar with that.

Gemma Anible:

I feel-

Matt Stauffer:

Yeah, I wish wasn't so familiar with that.

Gemma Anible:

I know, right?

Matt Stauffer:

Yeah.

Gemma Anible:

Okay, there's one for the real command line geeks. Again, if you're using a GUI, this is probably already available to you easily but you can grep diffs. You can grep the commits for changes that happened inside that commit with git log -G. You can give that a pattern of regex or whatever. That'll find any commits that pattern changed in.

Matt Stauffer:

Wow.

Gemma Anible:

Yeah. That's also really handy if you're trying to figure out when on Earth did I mess with this function?

Matt Stauffer:

Or when did this typo get introduced.

Gemma Anible:

Exactly, yes. I've used it all the time. How long has this been broken?

Matt Stauffer:

Yeah, exactly.

Gemma Anible:

It's like, "Oh, a year and a half." Awesome. That's great.

Matt Stauffer:

Yeah. Wow, great. Awesome. I guess I still got a job but I like that.

Gemma Anible:

Yeah, fix it. It's fine. Nobody saw nothing.

Matt Stauffer:

Awesome. Yeah, exactly. All right, I want to do the 22nd version of Bisects for anybody. If you've ever been asked to guess a number out of a hundred and your way of doing it was by starting at 50 and they have to ... you have to guess a number and they have to tell you if it's higher or lower.

Matt Stauffer:

If you started in 50 and then they said higher and then you started at 75, and they said lower, that's basically the same thing that Bisect does for you. It's a little smarter but it basically allows you. It walks you through this process of, "Hey, is the bug here? No? All right. Is the bug here? No. All right."

Matt Stauffer:

It's a smarter way of allowing you to step through that process. As long as you can easily tell whether that bug is there at any given moment, GIT Bisect walks you through the process of finding the point where it appeared or disappeared. I'm so glad you mentioned that because it's brilliant.

Gemma Anible:

It's a great feature, I love it.

Matt Stauffer:

I just want to show you the secret. Is there anything else you want to talk about on this topic, about GIT in general?

Gemma Anible:

No. We talked about ... I did want to make sure we covered Rebasing but I feel like we did cover Rebasing. The biggest thing about Rebasing is don't be afraid of it. Don't be intimidated by it. First of all, it can totally be scary and intimidating a hundred percent but it's GIT.

Gemma Anible:

You can always get back to where you were. You could always get back to where you were. Go to town. Break things. End up with two weird lines of duplicate commits that suddenly merged and now you have this bizarre history. Go nuts.

Matt Stauffer:

I love that.

Gemma Anible:

You can always get back to a known good state with GIT using the ref log.

Matt Stauffer:

My literal next question was, can you tell us what the ref log is?

Gemma Anible:

Yeah. So the ref log is ... if GIT is a history of how the files changed, the ref log is a history of how you move through the repository. Every time you check anything out, every time you merge, every time you rebase, any GIT action you're doing where you're moving around inside that graph, it's going to be recorded in the ref log.

Gemma Anible:

That includes if you rebase a branch, the old commits, the original ones. We've rebased, so you've copied a bunch of these commits. You basically duplicated them in a different place. The ref log still has them in the original place. You can get back to them there if you need to for some reason. That's true for really every operation that you do in GIT.

Matt Stauffer:

Yeah. I'm going to tell you all a story and I'm just going to make sure that I'm not telling fibs but I'm 98% certain this is true. Hopefully it will give you confidence that you can experiment like she was saying. In this story, a junior programmer has read on something somewhere that when you get that error that it says, "We can't push because there's conflicts in the remote," that the solution is to do a git push -f origin master, which is the force push.

Matt Stauffer:

One day, they opened up a project they had been working on for ages and they were asked to change the copyright date. They changed the copyright date and they tried to push. Of course, they got an error because the entire rest of the company had been working on that master branch for six months.

Matt Stauffer:

Instead of pulling down the last six months of work, they hit git push -f origin master. Now force pushing in that context is not that bad of a problem because, of course, everybody else who's working on the project has the last six months in the locals. Except in this particular circumstance, one person had left and their machine had been scrubbed and then the other person did a huge deletion of everything.

Matt Stauffer:

So basically that person, that the GIThub version of this thing was the only existing version that had the last six months of commits, and the junior programmer had just accidentally forced pushed over it. Everyone thinks the world was over and then the team learned about the ref log and they could actually go understand that those six months of commits were still in there and could be extracted.

Matt Stauffer:

Am I right? I twisted the story a tiny little bit but I'm pretty sure that's exactly how it happened and that is possible. Even though you're sure you force pushed, it's gone forever. It's all still in the ref log, right?

Gemma Anible:

Yeah. It's all still in the ref log. With GIThub in particular, GIThub is now very helpful with this. If you force push something, it'll say if it's a pull request or something, it'll tell you, "Hey, this used to be this commit. This branch used to be this. Then there was a force push and now it's this commit." You can get back to that commit on GIThub.

Matt Stauffer:

That's helpful.

Gemma Anible:

Yeah.

Matt Stauffer:

Just know, even that circumstance, which just seems completely irreconcilable is totally fixable. It's not like the ref log is just something you just click a button on. You've got to do a little bit of learning the ref log, unless you have that GIThub that you're talking about.

Matt Stauffer:

If you get in that situation, don't freak out. Just Google ref log and you feel like you can't handle it, reach out to somebody who's a GIT pro and say, "Can I pay you to help me pull something out of the ref log in this issue?"

Gemma Anible:

Yep.

Matt Stauffer:

Okay. So if I were to want to learn more, are there any places? Now you already said there's tons of materials out there and I agree with you. If the answer is, "You know what? There's so much out there, there's not any one I prefer," that's fine. Are there any one tutorial or resource or anything that you've said consistently, "This is absolutely the best place to look for learning about GIT?"

Gemma Anible:

There's a couple that really comes to mind. The official GIT website is git-scm.com, I think.

Matt Stauffer:

I think so too or .oracle.

Gemma Anible:

Yeah, something like that. That's got everything. That has full reference for all of the commands. It's also got the Pro GIT book, which is available to read online. That is a fantastic resource. That's a great place to learn about how GIT works and how you can move around in it.

Gemma Anible:

The other resource that I really enjoy is the learn GIT branching site, which has been around for a long time. I think the URL has changed. I'll look it up and I'll give you whatever the current one is.

Matt Stauffer:

Learngitbranching.js.org and I'll get it in the show notes too.

Gemma Anible:

Yeah, there you go. Sounds right. That is an interactive graphical representation of a GIT repository that you can change with GIT commands.

Matt Stauffer:

Very cool.

Gemma Anible:

It's a place where you can type in GIT commit, GIT commit, merge, branch, whatever. It'll show you what those commands are doing in this graphical representation.

Matt Stauffer:

That's awesome.

Gemma Anible:

That is super, super helpful. I like that one a lot. Those are the ones that really come to mind and then obviously stack overflow.

Matt Stauffer:

Yep, and the Google.

Gemma Anible:

Always stack overflow.

Matt Stauffer:

Yeah. Increasingly over the last six months, I very seldom check analytics in my blogs. Every once in a while, I open up just to see if there's anything happening I don't know about. All of a sudden, over the last six months, I wrote a post about "GIT Cherry Pick."

Matt Stauffer:

If you're interested to learn about Cherry Pick, just go Google "GIT Cherry Pick Matt Stauffer," and you'll see it. Apparently, I'm one of the top results for GIT Cherry Pick, and all of a sudden more and more people are coming to this one very simple thing that I wrote four years ago.

Matt Stauffer:

There's definitely a good amount of people out there Googling how to merge a commit from a specific other branch or something like that and getting into this GIT Cherry Pick one.

Matt Stauffer:

All right. Finally, I'm going to get down to the personal fun moment. Who is Mara Jade Skywalker? I wanted to see if there's anything that's been happening in your life that I haven't followed because I've been totally off Twitter for ages. I like star Wars. I grew up with Star Wars but I never got in the books or anything. I saw you just relieved beyond belief that Mara Jade Skywalker had not been introduced in the canon. I just got to know, who is Mara Jade Skywalker?

Gemma Anible:

Oh, my gosh. Yeah, okay.

Matt Stauffer:

I know I didn't prepare you for this.

Gemma Anible:

No. I could also talk about Mara Jade forever. It's no problem.

Matt Stauffer:

I've never heard her name until I saw that Tweet.

Gemma Anible:

Yeah, okay. So you didn't read the books. I think it might've been '93, maybe early mid-nineties. Timothy Zahn wrote a trilogy of books in the Star Wars universe. These books kind of spawned ... I mean, there were a couple of books before this but it was really this trilogy that took off and the Expanded Universe of Star Wars took off in a huge way in the '90s.

Gemma Anible:

Everybody started writing books and there was just tons of people telling tons of stories in this universe. The stories that he wrote introduced a character named Mara Jade. I don't want to say too much because you kind of ... Mara Jade Skywalker, that's the spoiler.

Matt Stauffer:

I imagine she's related to Skywalker in some way. That's as far as I got right now.

Gemma Anible:

She wasn't. She wasn't initially.

Matt Stauffer:

Okay. She married in.

Gemma Anible:

She was kind of like a force sensitive ninja commander person who worked directly under the Emperor. She was his hand. She was the Emperor's hand.

Matt Stauffer:

Oh, yeah.

Gemma Anible:

He would send her all over the galaxy to restore order, assassinate people, whatever. She was pretty hardcore. When he was killed, they had this a psychic force link where he was able to just give her commands from anywhere and she could see him and they could communicate no problem. She was force sensitive but he never trained her as a Jedi or a Sith or whatever.

Gemma Anible:

All of her abilities were instinctual.

Matt Stauffer:

Or latent.

Gemma Anible:

When he died, he just blasted her with, "You will kill Luke Skywalker."

Matt Stauffer:

Oh, my goodness.

Gemma Anible:

That becomes her life's mission.

Matt Stauffer:

Oh, my God.

Gemma Anible:

Of course, then Luke Skywalker runs into her and she can't kill him yet because she needs him for this thing that they're doing. The whole Timothy Zahn trilogy is the story of how that works itself out.

Gemma Anible:

Spoiler alert, she does not. Well, she kills Luke Skywalker but she also doesn't kill Luke Skywalker. So you'll have to read it.

Matt Stauffer:

Okay, you have to read the books if you want to know what that means and why her name ends up being Skywalker in the end.

Gemma Anible:

Right.

Matt Stauffer:

Okay.

Gemma Anible:

Her name ends up being Skywalker at the end because Timothy Zahn's set up, he set them up beautifully to be romantically involved and nobody touched it. None of the other authors for a decade. It can't possibly have been a decade. It might've been. Nobody touched it. They brought in other women, never Mara.

Gemma Anible:

Finally he was like, "All right, screw it. I'm doing this myself." He wrote a couple more books.

Matt Stauffer:

Oh.

Gemma Anible:

Also with Mara Jade and Luke and they get married.

Matt Stauffer:

So there was a Mara Jade who was a figure of significance and then Mara Jade Skywalker is what he did later with this Mara Jade character.

Gemma Anible:

Yeah. it's the same character.

Matt Stauffer:

Is his later work considered any less or more canonical than his original trilogy?

Gemma Anible:

What is canonical and Star Wars is a whole other ...

Matt Stauffer:

Did it change at some point?

Gemma Anible:

Yeah. None of this is canonical now. The whole Expanded Universe is now ... it's the Legends. None of it's canon anymore.

Matt Stauffer:

They uncanonicalized everything in early 2010s or something like that?

Gemma Anible:

Yeah. It was actually when Disney ...

Matt Stauffer:

Yeah, so Disney took it over and said, "All that stuff is no longer actually canon. We want to tell our own stories and not have to listen to 500 different authors saying, 'Well, I did this and this'." Okay, cool. I don't know how the Star Wars fans feel about it but I can imagine as a company telling stories. Have you ever read Ender's Game?

Gemma Anible:

Yeah.

Matt Stauffer:

Ender's Game is one of my favorite series. I know the author has problems but there's two.

Gemma Anible:

You know, he can spin a good yarn sometimes.

Matt Stauffer:

Yeah. So there's two forks of the Ender's Game story. You get to understand the story and then one fork follows his friends and this guy named Bean on Earth. Then the other fork follows Ender as he goes out in the universe and does totally very different, very heady type stuff.

Matt Stauffer:

Then he said, "You know what? I never told the story of the moment between when Ender left the end of the book Ender's game and when he went off to all these adventures. I'm going to go back and write this story that bridges the gap between those." He had already written 20 books, including a whole bunch of them that are ... I don't know how many but there were about that time, post-Ender leaving, post-Ender's game and the Bean series.

Matt Stauffer:

Now, he had to tell a story that's in the Ender series. The Ender series always kept Ender as the hero just like the Ender's Game book was. The Bean series almost retconned a little bit sort of saying, "Ender wasn't quite that much of a hero and without Bean, he never would have been totally a hero."

Matt Stauffer:

Which is fine because when you're reading the Bean series, you love Bean and it's very cool that he gets to be popular. When you're reading the Ender series, he's somewhere else. Him being cool and interesting doesn't detract from Bean, except in this one book. In this one book, they try to go back after the fact in the Ender branch of the story and tell a story about Ender immediately after this, that includes all the new continuity understanding that had been established by the Bean series where Ender was lame and Bean was great.

Matt Stauffer:

It was the worst addition I've ever experienced in a series because they were so constrained to try and tell a story. He said, he literally had dozens of people from the forums basically helping him write the story and make sure he didn't say things about Ender that were proved to be not true.

Matt Stauffer:

It was awful. I was like, "You should have just not written the book." I can imagine, if you're trying to tell a good story and you got people saying, "Well, that doesn't line up with this." You're just like, "Dude, just let me." I feel that's probably why Star Trek rebooted their series in the last couple of movies.

Matt Stauffer:

They're like, "We're going to do a universe changing event so we can tell the story however we want because we don't want to deal with you all the time."

Gemma Anible:

Yeah. No, exactly. I don't think Disney could have made any other choice but as somebody who was a huge fan of the Expanded Universe, it was gutting. It was like there were all these characters that were as real to me in the Star Wars Universe as the name Luke and Han and Leia and Chewie.

Matt Stauffer:

They just got thrown to the wayside for that. That's tough. I hadn't thought about that.

Gemma Anible:

What's killing me is they're starting to bring them back now. They're starting to bring some of these characters that were very well loved back into canon using some of the animated stuff that I haven't really watched. One of the characters they brought back was Grand Admiral Thrawn who was also in these Timothy Zahn books.

Gemma Anible:

He was the primary antagonist. They used a lot. They used a lot of the original Thrawn material. There's a concern that they're going to bring Mara Jade back. I would prefer that they not because I think she was great and I don't want them to ruin her.

Matt Stauffer:

Oh, it's not that you didn't like her. It's that you don't trust them to treat her well.

Gemma Anible:

Yeah. No, she was fantastic.

Matt Stauffer:

Yeah, because you were relieved in that Tweet that started all this. I was like, "Oh, you must have hated her."

Gemma Anible:

No, I loved her. I loved her. She's a fantastic character. I loved her.

Matt Stauffer:

Interesting.

Gemma Anible:

I was reading this, I was 15-16. This was candy.

Matt Stauffer:

I feel I have to go at least read those three, the original trilogy now. My family ...

Gemma Anible:

You know, if you ask me...

Matt Stauffer:

Oh, go ahead.

Gemma Anible:

Well, it's not like high art. Don't walk into it expecting literature but I still think they're pretty entertaining stories.

Matt Stauffer:

My family grew up watching the Star Wars movies and the Star Trek TV shows over and over and over and over again. We were like mid-level nerds. I know all the Star Trek characters. I've seen all Star Trek shows. I've seen all Star Trek movies and I've watched the Star Trek movies, the original trilogy a jillion times but I never got into the toys, the books and all that kind of stuff.

Matt Stauffer:

That's why I'm like a half nerd there. I think my half nerd takes me nerdy enough to want to read those books, even if they're not high art.

Matt Stauffer:

Okay, I had been waiting to ask that question since I originally wrote these notes. Last thing for today, how can people follow you? How can they pay you money or support you? Where are your preferred platforms? Are there any things that you're doing or selling or want people to pay attention to or anything?

Gemma Anible:

That's a good question. I'm on Twitter. I'm also on Mastodon and most of what you see on Twitter is actually stuff that I've posted on Mastodon and then gets pushed Twitter.

Matt Stauffer:

Just autoboted over.

Gemma Anible:

Yeah, because Mastodon is neat. Mastodon is like the early days of the internet returned. You can follow me wherever if you feel the need to do so. I don't really have anything I'm selling or anything I'm building.

Matt Stauffer:

That's okay. You have a job.

Gemma Anible:

Yeah. I know, right? Yeah, I'm a software engineer at WonderProxy. If you do have a need to do any localization testing, if you operate in multiple markets, if you need to show different ads to different markets or need to show different languages to different countries or you're worried about GDPR and where is that going to show up versus where is it not going to show up, localization testing can help you with that and that is what we do at WonderProxy. So you can check that out.

Matt Stauffer:

Link in the show notes. Yeah, there you go.

Gemma Anible:

WonderProxy.com in there. Yeah, I think that's probably it.

Matt Stauffer:

No, that's great. Is there anything else you wanted to cover in any way, shape or form? Whether it's Skywalker or GIT or anything that we didn't get a chance to get to today?

Gemma Anible:

They killed off Mara Jade eventually in books and I was really mad about it. That's it. That's all.

Matt Stauffer:

Maybe if they bring her back from the series, they won't do that then.

Gemma Anible:

Maybe even.

Matt Stauffer:

You don't trust them.

Gemma Anible:

I don't trust them. I don't trust them.

Matt Stauffer:

Got it. I might put a spoiler noise right before you said that just in the final podcast. "Star Wars Spoiler."

Gemma Anible:

Yes. Although honestly, I think it was probably ... Gosh, what year is it?

Matt Stauffer:

Probably 10-15 years ago? Yeah, it's 2020.

Gemma Anible:

Probably like a decade ago that they did this.

Matt Stauffer:

Yeah, I think at this point the spoilers are spoiled.

Gemma Anible:

Yeah.

Matt Stauffer:

Yeah. All right Gemma, thank you so much. You are a pleasure to have on the podcast. I learned a ton and I'm always trying to tell everybody, "You're going to learn a ton," but it's always a joy for me when I get to learn things. Thank you so much for teaching us. Thank you for so much time out of your day and I really appreciate it.

Gemma Anible:

Well, thanks a lot for having me. This has really been a blast. So thank you.

Matt Stauffer:

Awesome. All right, see you all next time.

Gemma Anible:

Bye guys.