 Two branches to bridge and get. And sad I could not merge to both. I merged to branch and less travel by. And now I'll build to work. I'm Corey Cohen. I generally tend to spend most of my time managing engineering teams, usually cycle liability engineering. I'm picking a couple of points off to be compressed, and I'm figuring out what's next. But for now, I'm spending that time traveling around and inflicting my personality on audiences like you, so sorry about that. My Twitter handle is up there. Please feel free to tweet at me as soon as appropriate. I'm always thrilled to get people asking me questions, including but not limited to what is wrong with me. Okay, let's talk about kids. I'm going to start off by promising something, specifically that everyone in this room is going to learn something. If you are one of the kids authors, you're about to learn how I mistreat your baby. I'm sorry. One thing I do want to call out though is that I'm about to make fun of a lot of really stupid things you will do with kids. But everything I'm about to make fun of, I date in production. So the best way to really own your failure is to turn into a conference talk. The hard part I have is finding enough conferences to list all the stupid things I've done in my life. So this is a start. When you screw up on something, phone it. So let's start at the very beginning here. Who here uses Git? Who here wishes they use Git? Who here is raising their hands because they're staring at their phone or their laptop and they want to pretend they're engaged? Hooray. So what does Git do? It tracks changes to files and directories over time. It helps us collaborate with each other. And Git is very, very simple at its heart, which is a matter of wanting these presentations. The next slide looks something like this. Yeah, that's about as clear as mine, because there's an elephant in the room. So let's go ahead and introduce it. No matter who you are at some point, you wind up getting very confused by something, kids. And you don't know what's next and you're struggling for staff overflow. The only question is how far out do you get before that feeling hits. So why is it so complex? I propose absolutely nothing. Git was written by Linus Torholz, who is famous for three things. The first is writing Git, which is why we're all here in this room right now. The second is creating Linux, which is why most people in this room are employed. And of course calling people morons. He's really good at all those things. So despite its complexity, Git does let you do some extraordinarily powerful things. Powerful, of course, in this talk, he's a polite euphemism for stupid. Let's go over to the demo room. Good, good, good. This shouldn't be too much of a surprise. I'm creating a new repository inside my current directory. I'm blindly adding everything. Your first indication you're doing something costly dumb is what it hangs for a while on a local operation. It is designed to be extraordinarily fast. It's one of the big benefits it has over previous generations of version control tools. So, okay, what it finally commits then, we're just going to ignore that. We're going to finish that operation. We're good. And it tells me, basically, that it has, in fact, a file here called Ubuntu.i.sup. It created the document subdirectory that contains all the repository metadata. And that repository is now 173 megabytes in size. Well, that seems a little suboptimal. It makes that commit. If I run a Git status, sure enough, it tells me that it now has a data contract. It can't be added to the repository. But I still have an enormous Git directory, because what Git does, fundamentally, at its part, is it retains a snapshot of every commit dating back to the creation of the repository. So, there are not a lot of great use cases for committing large binaries directly into Git. You can do it, though. Git is not opinionating that sense. You can commit large binaries. You can commit atrocities in Git. If you wind up needing to store large binaries, there are two tools out there that tend to really speak well. One is GitS, which was created by Joey Hess, a devian developer. And Git LFS, which is supported by Jithub or GitHub, depending on the pronunciation side of the class, and they're sponsoring a lot of development on Git LFS. Now, most of us aren't committing large binaries to Git repositories after the first time we make that mistake, but we do often commit things that we probably shouldn't be, like secrets. If you wind up accidentally committing this to a repository and you don't want to blow the whole thing away, there are ways to extract data, really come down to either Git filter branch, which is arcane, confusing, and annoying to work with, or DFG, which is written in Java and winds up causing tremendous piles of stress, but it's fast. It's great for stripping out things like API keys, et cetera. This is not just a trivial act of work that people are doing this on a non-growing basis and finding that there's suddenly someone that needs to spun up a bunch of Amazon instances to mine Bitcoin. Well, some shops do say they commit secrets to Git, but they encrypt them first using a variety of different technologies. So, let's go on to another terrible idea. You can, well, I don't even really know rightly what this is. So, we create a repository. We take a look at what's inside of that sub-directory. This is the heart of what makes it make use recall. It contains metadata. It contains objects. It contains pointers to what the current state of the branch is. It even has a local configuration that's repository-specific and hasn't Git books, but all of these are just files and directories like anything else. I like keeping track of these things. There's a tool I like to use to do it. Yes, that is a Git repository inside of Git repository. You can keep doing this, and believe it or not, it does work. I have no earthly idea why you would, but you can. Well, it doesn't even hurt to have to use so long files. Exactly. See, someone gets what we're talking about. How come this Git repository is a good space? Do you feel anything I check it out? Well, funny story. Yeah, it doesn't really matter. How often has this happened sooner or later? Maybe I'm being a little tight about it all the time. How often does this happen to you or something like it? You start typing a command, and because I tend to get commands and get code in, I'm a full stack over, float it over. So what I end up doing is copying and pasting from stack over to the command I want. Let's pretend for the sake of argument, it's Git status. Hey, Git is not an exponential command. Did you mean this instead? Yeah, so it's, that's not really great. But there are ways to fix this. Notice that this Git's in a tweet. Oh, absolutely nothing. That's where I still live from years ago. But, and then it works. You can go deeper. You too, these trains are leaving. And it works. Something very similar to this will make Docker, Docker, Docker a reality soon. So Git does have built-in support for aliases. You can use relatively long complex things in aliases to a short Git command, but it does tend to have some limitations in that model. For example, everything you call out has to start with the word Git, which is suboptimal. So if you want to do anything that doesn't require the inside Git portal or going a little larger than that, you often have to back up the shell itself. For example, I can set shell aliases like this. Now, why in the world would I do something like that? It used to be the appropriate time to point out that you invited me to speak here. That's on you. Okay, let's talk a little bit more about Git in this case. Specifically, I feel like this should really be on the Git marketing page. You can have a great and common license to Git's yours. We've all heard about revacing master and then doing a force push with a laritist prank that all of your coworkers won't join. What that does is it changes the history so that suddenly what happened before is not what people are actually working on and everyone else wants them getting screwed in the process. If you've heard, I saw my doctor talk yesterday, you heard those jokes, but you get to hear it again now. A group of whales is called a pod, a group of crows is called a murder, and a group of developers is called a merge conflict. Now, I historically come from an operations background. I was a growth field assistant and I don't have time for that nonsense. So instead, I use this because it's faster and... We are the department of no. On a more serious note, if someone does do something like this and do a few options, you can repush from a no good copy somewhere else. You can refer commits and get things back the way it used to be. You can hold responsible screaming from the roof of your office. The actual solution this is going to depend on the specifics of your environment. This is also why I turned on branch protection. If you are upstream GIFs or supports that, it's generally a good idea. Re-vacing and pushing feature branches, fine, terrific. You're the only person that's doing it great. Shared development team, great way to come up paying. So, we've shown that GIF is reasonably effective in making us feel stupid. So let's turn that around a little bit. Let's help you make you feel a little bit smarter. How many times has this happened? And it winds up saying, hey, status is not a GIF command. Do you mean status, moron? And you sit there and you feel dumb. How did GIF help you with this? And I'll insect this command in a second. What I'm doing there is turning on GIFs auto-correct functionality. I talk to that same command, press enter. It tells me that it assumes that I'm going that I met status. And it gives me eight tenths of a second to practice. Before I ruin someone's life. To break that to the end now a little bit, what that does is it's running GIF config, which is how GIF configures itself. Global tells it to use the configuration file in the user's home directory. There are three places that it will store things. If you use system instead, it goes into XE GIF config, which is awesome to really confuse people why GIF is different on that particular node. And the default is it will make that change only for the repository you're in, on the machine you're in, which makes it even more confusing for people, which is just awesome. The auto-correct turns the toggle on and the eight is tenths of a second you have until the command executes. You can set that to 80 and have an eighth second long wait of shame. You sit there and reflect on your more typing skills. Now this is fun and it has, it does work, but it does have limitations. For example, it'll only work if there's a single command that it could be. If I type in git c in press enter, it's not going to assume that I'm being commit or config or anything else that could potentially start with a c. So, you know, it's cool, but it doesn't always go far. So, how often has this all happened to you? If you try to push and say, eh, there's no upstream tracking in where it's set and this upsets you so you type profanity into your terminal and then it works. Just forget. It's the ultimate do what I say, do what I mean, not what I say command. More notable than the technical accomplishment is the fact that this is the first result on Google when you punch in the fuck. That is masterful SEO. So, humor aside, I do have a few legitimately useful tools that I want to present to you folks today. Let's face a bit of an uncomfortable truth. Speaking as a manager, an awful lot of my peers tend to present at times like semi-intelligence swirls looting desperately for something shame. So, when I was at a previous job what happened was I had just taken over the team. The monitoring system was completely defunct and not presenting anything. And the display sitting next to my desk was showing data that no one cared about. I didn't have a whole lot of time but I wanted to do something to trick my new co-workers into making the fatal mistake of coming behind and talking to them. So, I think I wanted to put something interesting up there. And here's what I did specifically. It's a tool called Gorse. Okay, it's a tool called Gorse. And what that functionally does is it traces the git repository it traces the git repository through time and winds up just presenting a visualization of this. So, you have different developers coming in and making changes to things and it's very visually appealing. And what happened next was kind of interesting. I mean, technically it's great, it's pretty, it doesn't quite a whole lot of value but people can end up telling stories. They'd say, oh yeah, remember where's that module in or in the early days of the company you'd have one of the founders going in and changing to a bunch of files. And then one of the engineers going in and really reverting all of the changes and changing to a bunch of files. And it becomes more of a shared narrative. And that was something that was fun. So, it doesn't take a whole lot to do. This is available in its open source software. It is available in Homebrew for Mac. It's available in almost every, the next best part is available. I don't know our characters, they're the one with us. I'm sorry. So, audience participation time. Let's start with the poll. Does anyone here have more than one gift or concert score that they care about? Look around the room for people without their hands branched. They work at Facebook. For everyone else it sometimes sucks to realize that you're on a plane and you're missing the latest change that one repo you need. Or after working on stuff for all you realize, in a way they're working on a week old revision rather than with current data. It's unfortunate. Mark Atwood over at HPE, last I checked, had a decent solution to this problem that you may not post it. You punch a fine command, it will forward you to find gift repos to get it right over it and potentially it changes, and that's where I'm at this point after being asleep here. This works, and it's really awesome except for the part where it's shitty to remember it, type it out, et cetera. I run it every time. So, I might do something like this once, but I'm not going to go down that road every time I want to update stuff, even with an ambulance. So, I took back of him. I took that painful loop, but instead of running a gift fetch, I ran a different command. In this case, MRRegister. And he responded, this is awesome, thanks. I'm going to bring this up. It's not solely to say how awesome I am, but to point out that we are all always learning. Mark is someone who has forgotten more about software than I'll ever learn, and he was unaware of this thing. We all tend to stand on the shoulders of giants in this space, and we're also almost never the first person to have a particular problem that we're wrestling with, and everyone around us has holes of their knowledge that are different from the holes that we have. So, when I came here, it was something mindingly obvious that if they said it out loud, people around would say, wow, that's great. It becomes amazing. During the Q&A section, for some of my talks, people sometimes raise their hand and say, well, I have a really dumb question, and you see people in there are gas or really dumb question, but when I dig in and answer, those people are taking an awful lot of notes. That's because it helps people around us. Open source has always been about community and about giving back. So, let's talk about what MR is and does. They changed the name from MR to MyRepost to make it easier to find, but I still haven't gotten a hang of it quite yet, so I still refer to it as MR from time to time. They've managed to take the traditional hard problem in computer science and naming things, and made it worse by renaming something. So, step one is you run MR register inside of a given retail. You can automate it by that loop, you can do it by hand, but either way, it doesn't really matter because you only got to run it once. This in turn winds up building a config file in the user's home directory. The next thing you do is you run operations across all of those repositories by replacing git with the word MR. And I will, in fact, give a demo of this. So, if I go ahead and type MR list, it tells me everything that it's managing now as far as repositories go. Note that this in turn winds up only working at the level that you're running the command at and below. It does not go above this. So, if I go up one more level, I go running four to having eight, and it tells me where all of these things are. So, I can do an MR up and it will automatically go update one at a time, and so on and so forth, over a slow connection. Or I can give it the concurrency flag, dash, dash, job, or dash, j, so what does this mean? And it will do all of these things simultaneously. We can pretend that the wires would be hated by itself. Like that. If you look inside of the MR config, we have a few default commands here, in other words, different commands if you want to potentially alias, as well as giving us an input section that includes other files. So, I can have a separate MR config that looks a lot like this that is specific, for example, to our employer. So, here's just the list of things at this company, and there's a 50 depositors to care about that I want on my machine. But I don't want those on a whole of my machine, so I can start breaking them out that way. We point to where the repository lives and it tells the rest. If we're pointing out that this supports a number of other version control systems, it is not specific to yet. Perforce is not on this list, but patches are always welcome, which is the open-source polite phrasing for go away, kid, you bother me. The third step to a tool like this is to pass it on. Because I didn't know that this tool existed if a stern German friend of mine hadn't told me about this. For all of their faults, Docker gets this perfectly rapid, and the first rule of Docker is never ever shout out about Docker. It's the inverse fight club. One more tool that I do want to point out is called DCSH. It was written by a different dev team developer and the stern German friend who pointed out it and murdered me. Who here has a global .files repository that they wind up keeping somewhere? Yeah, okay, so it's a fairly common approach. It often looks a lot like this. And I argue that this is a suboptimal slash groundy way of managing your .files if you have multiple machines. For example, I don't want I have a gift repository that has my personal AWS credentials in it, most of it because I'm a moron. But I don't want that living on my work machine. And I don't want anything that has work credentials living on my personal machine because I have hobbies that don't extend and get exude. So what I wind up doing instead is using something called an MR that lets me be a little bit more prescriptive with regard to what repository, what things are checked out. Sorry, VCSH. What is the wrong term here? So my VCSH list it shows me a bunch of different repositories that I'm currently managing. In this case let's use SSH By running that, what I've now done is I've dropped into a environment where I'm now inside of a gift repository which does live elsewhere on the disk but it is controlling files in this directory. So if I do a gift status Yeah, in this case it shows that the only file that I'm managing is my .ssh slash config. But if I show where I currently am I'm still just hanging out in my home directory because my location hasn't moved it's no longer tracking any other files in that incident of the way I avoided grabbing everything which is really not a fun game to get into checking your entire home directory into a gift repository what's the possible gift repositories? Is that I dropped a giftignore file in there with the wildcard info. What this means is that if I want to add a file to a VCSH repository in this context I do have to give it the file which is .f which is a relatively small price to pay as I see it to in order to manage these things So I make my changes I then log out and I'm still right where I was so you can have different remotes for it and it effectively lets you manage multiple repositories control what is in a common directory. It doesn't go all the way but it does go a long way toward combating the use and misuse of another terrible idea that specifically gets up on this also known as a reason to do it. So what this is doing just to run through this event is I wind up having an MR I use my .config directory which is a xdg where this is originally the camera where I have a .config where I stuff a lot of these things. There in turn is an MR directory in there which this both what is available and then what's simulinked into what's on this note. So in this example I would for example have a vimperator option in available.d that is not simulinked in. So as long as I don't simulink that it's never going to check that repository out on this box which means that data isn't there. All I have to do is just add or remove that simulink and it winds up controlling what winds up being in there. The repository itself lives under the VCSH config so in this case we have a csh.git bear repository there that then in turn winds up having files checked out into the pair and I will have a link to this tool there. I do have two last tricks that I want to point out that I've been showing you without calling attention to the fact that I've been showing them to you and they look a little bit like this. As I'm inside of the git repository I notice that my prompt is changing all the time to reflect what the current status is. In this case it tells me I'm on the master branch and there's a red dot and a red one next to it. And what that's telling me is that there's a file that is staged but not committed. Once that's done that red dot turns into a green check marker which in turn tells me that this is again how to put up the status command of I'm on the master branch and my branch is ahead of origin master by one commit which explains the up arrow of the one next to it. One bit of course later and I'm in a position now where it's just master green check mark all the way. Why is this helpful? Specifically because it serves as a constant indicator of the current status of what I'm doing. It gives me a visual reminder that I don't have to ask for to tell me whether I'm on the master branch develop branch, a feature branch and what the status is. Is there a verge conflict that I should be paying attention to? How far ahead or behind that line? It just tends to help prevent us from looking at a level almost. Me from making specifics as often as I would otherwise. The last thing that I want to show up as well here is I haven't been running git for most of these. Yes? I like to use that. Does it have a good influence on the source that it needs forever? Yes. The quick question is our repeat for the video. The question was specifically what happens if you go to a giant directory and it takes forever? This is parsing the outputs under the hood of git status. Generally running git status, even the Linux source directory shouldn't take as dependent on my experience. Alternately, what's possible is your implementation of this might be ignoring that, or a library that takes a long time to iterate through things. It's going to depend. There's a lot of different tools that provide that functionality. The one I use is this is actually showing up to a Python script of all things. And it tends to be fast enough that I never notice a problem or even any noticeable lag of any machine since 2010. So I'm not saying that's the best answer to it, but that's how I would solve it. The last thing I want to point out is that I'm running Git as a wrapper script around Git. What it does is it intercepts everything that I wind up doing with Git that it doesn't understand that it's by itself. It passes it through to the native Git binary already installed in the system. But it does add a list of GitHub commands as well. So I can do pull requests, I can fork things, and it makes it a lot easier if you're working with things that are GitHub. I'm unaware that companies are offering the same type of wrapper script, but it's not that difficult to build and it's something that I'm strongly recommend. Feel free to grab a picture of this, these are links to everything that I've mentioned today that everything is a non-standard built into Git. I have a few things I didn't mention. Specifically, Git Hug. No, that was not a mispronunciation or a typo. It is a jam that you install. You run Git Hug. It's a level by level progression through doing different things with Git. It creates a new repo each time in a certain state and gives you a challenge to complete. Once it runs the tests and that challenge has been passed, you move to the next level. Last time I checked, there were 45 of them. It goes through basic stuff like how to add files to a staging area, how to wind up committing into you how to explore the ref log, how to wind up doing a binary search, how to do Git bisect, how to do all kinds of relatively complex remixes. It really there's a great way of getting up to speed in a relatively short period of time. So, with that said, are there any questions? Comments? Yes? Just put a comment on any time you have your recovery plan. Yes? So if you do a Git GC, it might beat it up. Okay. Yeah, that's possible too. It depends also on what you're doing in that repository and what the current status of it is. Your Git can find out especially on a relatively slow machine in a Docker container when you get a giant ISO into the repository. It turns out not what it's optimized for. I'm finally going to be up on that one. I'm sure that will get fixed for itself. Other questions, concerns, your resume disguises a question. Anything that anyone wants to start with me in fact? Perforate. Possibly. You have to add the .files repose to yourself, but there is now since I've been using this for a long time but since then they may be onboarding a lot easier with there's a BCSA bootstrap that gets you up and running which is a lot better than the common sense I used to have to do to get this stuff going. After you complain 15 times to people eventually they start fixing things. The trick to getting a change done in an open source project is to be so annoying they can't afford you, which is our life philosophy. Other questions, concerns, angry thoughts about kid workflows, happy thoughts about kid workflows. Alright, thank you all for coming. I appreciate your time.