So You Think You Know Git - FOSDEM 2024

[Music] yeah how is your name uh last name pronounced chakon chakon yep okay boy the pressure's on now I really feel like I have to deliver here um so it's nice to have this great Full House thank you all for coming out it's great to be at fdam um so this is not I feel like this should be kind of a keynote type thing with this nice big audience but it's really going to be a bit of a a a technical Tech you know boring talk so uh really really you know bear with me so just to introduce myself a little bit if you don't know um my name is Scott Chone I was one of the co-founders of GitHub I assume most of you know GitHub at this point it's been a little while uh I I used to do a lot of talks and go around and try to convince people to use git and why git was cool and now it's you know it's been it's been a while since then um but it's a very different type of talk so um as I've been giving talks what I've kind of learned is that there are some people that have never used anything actually raise your hand if you've never used anything that's not g wow oh I feel so old um all right I also uh I wrote this book called prit um so if you go to the git website and and you read the book there that's my book um it's open source Creative Commons license so so a lot of times if you search for something on Google or something with G it'll hit this which is is always embarrassing if I forgot something and then read about it in my own book that I wrote um which happens more than more than zero um and now I'm working on a git client uh called git Butler so if you're interested in that I'll talk about it a little bit later on um we just opened it on GitHub so um I I'll get into it a bit but um what I really want to go through is git so how many of you use git on the command line okay so yeah nerds um so so it's not worth it all so so how well do you know git right um actually throw out a a number if you think you know how many commands how many git commands actually exist somebody said 400,000 um so there's about 145 get commands that you can type get something right most a lot of them are useless a lot of them are or not useless but are useful for scripting or in the background or something like that there are 40 uh 82 porcelain commands there's 44 Main ones normal stuff that you would do add commit Push Pull rebase stuff like that um there's 11 manipulators so config and reflog and things that you don't use that often but kind of give you more more metadata um bunch of interrogators some interactors most people don't use these right I mean send email you might if you're working with a mailing list with kit um but P4 or SVN or CVS or there's a lot of CVS import there's a lot of those types of things that are around almost Legacy there's a lot of sort of Legacy stuff and then there's 63 Plumbing commands so there's a lot of stuff like cat file and and things like that that you can use you can use the script A lot of times but for the purposes of this talk that's not what I'm going to be talking about I I'm not particularly interested in the plumbing commands I'm not going to go into the the sort of nitty-gritty details of G I figure if you're scripting something if you're using ligit 2 or something like that you're already know most of this stuff uh that's that's not really the point of this talk the point of this talk is that I've started talking about get more often uh with Git but stuff and I've realized that stuff that I took for granted that I thought kind of everybody knew because it's been around so long a lot of people don't know so this is really kind of a refresher and to talk about some stuff that's that's new so there's a bunch of stuff that's new um for those of you that are more old school that that have been using git for a really long time you may not pay atten to what's new and get so I want to talk a little bit about that as well there's still an average of nine commits a day there's 10,000 commits in the last 3 years do you know anything that's been introduced and get in the last 3 years right like probably not probably most of what you've done you learned you know 10 years ago or seven years ago or whenever you started learning get and you don't know a lot outside of that so that's kind of the point um this is my friend Nick he actually introduced me to get when we worked at react together in 2005 so this is when git was 5 months sold when he had his first patch in and he told me about it so G is old enough to drink um not in the United States uh cuz we're stupid but here certainly um so what has changed what is new what is interesting so here's our agenda um I'm going to talk about some helpful config stuff if you don't already know most of you probably do I'm going to talk about some oldies B goodies some stuff that's been around for a long time that you've just may not know I'll talk about some new stuff that's been introduced in the last few years that you may not have noticed crept in cuz there's not really like a you know get newsletter that most of you guys probably uh pay attention to and then I'm going to talk about some big repost stuff which is actually very interesting to me that most of you may not know about but may not also have a need for anytime soon but I find it very interesting um and then at the end I'm going to talk about some new GitHub stuff some stuff GitHub has introduced since I left that I've recently kind of discovered and I find very interesting so I want to make sure you know about it too the style of this talk I want to call a shotgun Buffet so I'm just going to going to throw a bunch of stuff at you take what you might find interesting if there's something that might make your daily life you know a little bit easier a little bit better please you know you also don't need to take notes um I put these slides on our blog at GB so if you go to gb.com go to the blog this whole slide deck is on there if if if there's something you want to reference later so just keep an open mind let the shotgun Buffet hit you in the face and uh see if there's something interesting at the end all right so the first thing is how to configure stuff right so I'm going to give you a whole bunch of commands that have little options little command flags and stuff that you may not know about when you learn them you probably don't want to type them out every time so you probably want to do a setup an alias of some sort if you don't know how to do it or if you haven't done this type of thing before it's fairly straightforward you just say Alias do whatever you want to type and then if you type get that thing so if I type get stash with two A's it'll do stash Das D all I don't have to type-- all every time so what I like to do is kind of kind of set up a lot of things of how I like get to work and I'll show you a bunch of different things you might want to Alias but that's how you do that if you didn't know and D- Global makes it so that all of your git repositories have that and not just the one that you're in um I actually like D- all for stash as well this is kind of a side note but if you use stash and you stash something um it kind of leaves it in a weird state-- all will take away sort of all of your untracked files and kind of do what I thought get stash would do by default um but doesn't so just a side note um the other thing you can do is you can tell git if you say git in this case BB you can say run some other script and pretend like it's a git Command right so you can script something and the way you have to do that is by putting a bang at the beginning and then it says okay I'll give this sort of a shell prompt and I'll I'll run it as you can even put actual bash script uh on the command line that way and it'll run that so this is something that I put in a just a while ago to try to give me a better Branch output that does a head behind information and orders them by last commit and even uses the git description which most of you probably don't know that you can put a description on a branch but it actually lists it out otherwise git doesn't do anything with that information which is kind of funny okay the next config thing that I'll show you and then and then we'll get into the really fun stuff is include if so most of you might know um actually is there water around here somewhere I'm going to the rate I'm speaking huh on the okay great um get config so there's an include if director directive so so normally how git works is you're working in your local stuff and you run something and it needs to say okay I'm doing a commit what's my email address right or should I use gpg signing or something like that and normally what it does is it looks in your local. gitconfig and then if it doesn't find a value it backs up into your Global config sort of dotg config in your home directory but what you can do is you can set up something in between right so it actually has a third place to look in between those things um so in this case I'm saying anything that's under the OSS Direct Dory use this git config so I can sort of overwrite my email address for my open source stuff and anything that's in the work directory use this git config and so I can I can say here's my my work information for any of my work stuff which is kind of nice to to be able to have a little bit more flexibility so if we go in here and we look at this git config I'm I'm saying let's gbg sign stuff and use my my git Butler email address and if I run user. email outside of that it says here's the email to use if I run user. email inside of that subdirectory then it it changes the default right so if you want to have sort of here's all the stuff that that that applies to everything underneath this then go ahead and do that so that's the include if stuff okay so just the config stuff now let's go into oldies but goodies I'm actually I might pull the audience a couple of times because you're all nerds and I really want to know who knows some of this stuff and who doesn't know some of this stuff because again I'm not I'm not I've been doing this for a while and I don't always know so who uses get blame okay who uses G blame DL does anybody know what that does okay so it just blames a portion of the file so normally you run get blame and it blames the entire file and Pages it if you know the line range then you can say just blame this line range and a it makes it faster but B um it makes it more more understandable right because it's not it's not showing so much and the other cool thing is that you can do exactly the same thing with get log so I don't know if anybody's ever used this but this is super cool if you know a function and you want to know sort of the history of that function you can run get blame and get sort of the on liners or you can say get log and give it the the the the range and the path to the file and it'll only show you the commits that get blame would have shown you right but in order so you can kind of get a little bit more of a story of how that function kind of came together thank you huh thank you you are welcome well you're going to love the rest of this talk um the other cool thing you can do is you can say get log-l and then give it like a function name and it will try to figure out what that block is heris and do the exact same thing so if you it depends on the language and I actually don't exactly know what that heris is but you can say for example file right it'll say okay this is class file and so it auto automatically gives me the line range for that and just gives me the story of what that is all right so that is git blame the other stuff that git blame does and that Mo if you use a guey or if you use actually GitHub and this is particularly embarrassing because I wrote this implementation at GitHub so when I on GitHub for this it is entirely on me um but GitHub and most of the goys don't ignore whitespace by default when when it runs G blame um and there's more options you can give git blame so you can also say- C which says Tech code movement so if you delete a function and then move it somewhere else in the file it will remember that and it will kind of ignore that movement right when you when you blame that thing um so so it won't credit you if you moved a function um as owning that if you do it two times I don't know how many people know about command line options where you give it multiple times and it does different things um but it is arguably not the best ux I've ever seen and if you give it two times it says or the commit that created that file if you give it three times it says or any commit at all so it's much more expensive but it can really help you get if you if you have time I mean it's not that often you run and get blame you might as well do this every time right because it it takes more time but it's much smarter about trying to ignore stuff that doesn't matter so for example if we go back to this one it looks like mostly Kel did everything if I run get blame wccc and then give it the same thing it gives me very different output right and and importantly so because Kel moved this at some point but I told it ignore that like follow all the renames and all the movement and it turns out that Kel actually had very little to do with any of this code right and so blame by default a lot of times if you're refactoring stuff will not end up with a person who wrote that line of code um but you can tell it to do that and and it's a I would set up an alias for this okay and you can also see what file it was right so this file was changed multiple times and then we can see it moving around and who edited when it was named what file um okay another one get log DS how am I doing on time I'm doing okay okay get log DS pickaxe so this is a way that you can say filter all my git log output to anything that has this reg regular expression or this string in it um so if you removed a variable or added a variable anything with that that that uh string in it it will just show you that this is a really nice way of seeing when something was changed that maybe get grep wouldn't find because it was removed from the codebase and you want to know when it was removed from the code base um the other thing is ref log so this is a log of your references if you haven't used this it will do it by default on head and you can run get ref log and it will show you okay that you pulled and you did a reset before that and you you know did a checkout from a branch to another one and you a rebase and here's all the steps of the rebase but if you ever want to run like get reset and you think it's going to mess stuff up don't be too afraid because you can run get reflog and see kind of what every step of that was and you can always get back to where you were so whenever the head is pointing at something it has a log of that another real small thing and then we'll move on to new stuff um get word diff so if you run get diff it will give you by default a line based diff um which sometimes especially if you're you know using Tailwind can be really difficult to figure out what was the one class that was kind of added in the in the middle of this line um if you run get diff d-word diff it will do it as a word diff instead and so it makes it much easier to see if you know it's a word sort of a word-based diff um what the difference is okay um and then the last one I'm just going to say the last one cuz I can't remember how many there are um is rir which is reuse recorded resolution how many people have this turned on do you and know what it is okay so good number of people don't know what it is um if you have a merge conflict you can tell git remember this merge conflict and remember how I fixed it and keep that in memory it actually keeps it on dis as a as a hash but um if I see it again it can automatically fix it for me right so if you're rebasing stuff and you're hitting sort of the same merge conflicts over and over again you can turn this on and you only have to fix it one time and every time after that that g sees it it will automatically fix it for you um and so the way you do that is by saying re re-enabled I would just turn this on there's almost no reason not to do this it's not super expensive disc dis wise um and when you get a merge conflict it says hey I recorded the pre-image for this this conflict and when you fix it it says okay I recorded the resolution and when you get the same conflict again it says hey I staged uh this using the previous resolution so I saw the same thing and I just fixed it automatically for you so it's very nice if you're cherry-picking a lot or if you're rebasing a lot okay so that's oldies B goodies that's been around in get for all of those things have been around and get for a really long time how many learned something new in that section out of curiosity oh fantastic okay so now there's some new stuff so now nobody's going to know this um so one you there is a new option to get branch called D- column which if you've ever run get Branch um you'll see it just kind of list them out in alphabetical order which is one of my least favorite things about get Branch because that's not usually what I want to see um but there's some new options uh recently that they have one is column so you can do D- column or you can set a global config uh column. UI Auto and then if it sees this sort of list instead of sort of paging it as one line it will try to put it into columns graphically for you and the other one is branch. sort so you can sort your branches by default by in this case reverse committer date so I want to see the ones that have had the last commit first right the most recent commit first and if I run get Branch now it actually puts them into columns for me right so it's a little bit easier for me to kind of kind of see what this is so I set this on I really like this this skit Branch output much better the other kind of funny thing is that there's a new git command called git column that just takes input and puts it into columns it literally doesn't do anything else um so if you want to put anything into columns now get helps you all right another show of hands who uses force with lease okay good um so force with lease is the worst named and most useful option that I think it has um but I'll go through a real quick explanation of what it does so this is relatively common let's say that I'm Scott and I'm working with somebody named Tom and I edit a file can you guys read that it's okay right and I edit a file and I commit the file and I push it to the server and then Tom pulls from the server and he gets that file change and he changes the file as well and he commits it and he pushes it to the server fantastic we've now collaborated except Scott doesn't have that change yet and Scott just went to lunch and had a beer and thought you know what I really messed this up I should have done it a little bit differently and so he goes in and modifies file and amends the commit right or rebases his changes or something like that changes the history and he Force pushes fantastic so now Tom's change is gone right I just force pushed over it because I didn't think anybody had even seen that in the in the meantime if you rewind instead and you say force with lease what it will do is it will check to see what it thought the reference was and if it doesn't match it won't push it right because it seems like it's stale so you have to fetch first just to make sure you're up to date and then you can push if you push and it's the same it will do the force push right as long as your reference was the last one that's that's on the server so it's kind of a safe Force push so I just use this if you if you do rebasing or or amending or something like that use force with lease it's much safer than force and it does the same thing in the right circumstances um okay another thing I'll go through this real fast um signing commits who signs commits oh wow you are nerds yeah that nobody like no who signs Comm like usually it's it's somebody corporate because the the company kind of makes them do it or or um whatever but who signs up with SSH instead of gpg okay not very many so um there's now a new thing some people not me cuz I'm pretty smart but other people have sometimes a problem getting gpg to work uh and kind of you know reliably and so um but all of us have SSH and in open SSH as of a couple years ago I think um they released a a new feature where you can sign arbitrary data um and get a a signature out of it and so um that has been Incorporated in git and so now you can use SSH to sign your git commits in the way that you used to you can also do with gpg but it does exactly the same thing so if you want to use SSH instead of gpg um you can say It's actually kind of funny because it's not called signing it's the gpg format is SSH um and you can say here's where my public key is or Here's Where My Signing key is and then if you run get commits this is what a normal get commit looks like although I I left out the the message here um if I uh put that into like if I edit a file and I commit and I sign it and I look at what that that file looks like now I have this this uh gbg Sig right but it's actually generated from SSH but the cool thing is that GitHub you can upload your public key to GitHub or even use the same one that you push with and then GitHub will mark it as verified or or git lab or or you know if you have your own server whatever if you can do SSH uh uh commit verification it will verify um and then if I you know I mean this is kind of the problem with with with uh you know or why we're doing SSH signing right is because you can put some other email address and do a commit and push it and then GitHub will say hey this one's verified because I have the public key and I I match it to the email address this one's unverified and so if you're using GitHub or gitlab these things will work but yeah if you're signing your keys or you're signing your commits with with gpg you can sign them with SSH and a lot of a lot of uh things will work that way as well um little known and nobody in this room probably will use this but you can also put one guy one guy in the front uses this but you can sign your pushes as well so you can sign the sort of ref updates that you push to a server GitHub and gitlab do not support this so most most people don't use it um but uh I think kernel.org supports it and there's a hand like or if you do your own you can do this and then you can create sort of like an audit log or or a trust log or something like that that has sort of the ref the ref updates um and the and the signature so that is doable but you kind of have to run your own thing if you want to use that type of thing um the next thing is get maintenance who uses who's run get maintenance oh man oh all right so all you have to do everyone do this today go in to whatever repository you work on the most and run get maintenance start because what get maintenance start does is it adds I mean really what it does is it does this it it just adds this to your git config file um and it says strategy incremental I'll show you what that means in a second but what it really does is it adds a Cron job for get to run in the background every hour or every day and do maintenance tests on that repository right and most of the time that's just going to make lots of things faster F in a way that you'll never notice so run it because it's just going to make everything faster and you won't have to worry about anything so if you've ever run like a git command and you see like you know it's garbage collect it's running get GC it's like garbage collecting or pruning loose objects or doing something like that it's doing that but in the background so you don't it doesn't have to tack it onto another command that you run because there's something running in the background so this is what uh strategy incremental does it does mostly these four things uh it does commit graph generation which I'll talk about in a second prefetch every hour which I'll talk about in a second loose object collection and incremental repacks of of your packs but really all that means is just gets faster right so if you want to run it and just have it go in the background instead of uh uh after sequentially after you run a get command you can do that get maintenance start that's all you have to do um okay so now stuff that I I'm actually I'm curious how many people in this room work on a repository that is you would qualify as enormous by enormous would you say more than half a million files in your working directory okay okay good then there's seven people in this audience that are going to find the next 20 minutes useful um so so whether you like Microsoft or not uh I have a little bit of a bias because they bought GitHub and that was nice for me um but whether you like them or not they have put a ton of effort into large repository and monor repository supporting git because they moved Windows to it and windows is enormous so Windows is you know 3.45 million files on disk 300 gabes to clone like think about starting the job and trying to clone off of a git reposit like GitHub or something 300 gigabytes um for reference the Linux kernel is four and a half right so it's it's it's a it's a a chore um and so what they did is that they put a lot of resources into making large repositories and monor repositories work relatively well in the git ecosystem in The Last 5 Years um and I want to show you the tools that they did so the first thing they did was they tried to do a virtual file system um and so you wouldn't have sort of actually all of the contents of the files it would just be sort of on demand and it would go to a special server that they had and it request sort of you know file contents as it needed it in order to do something but it looked like you had all the files until you actually to access them and then it it pulled them on demand um and then they thought it's actually not necessary and they created this um project called scaler and scaler tried to do a lot of the things that I'm going to actually they did all of the things I'm going to tell you about now but then over time all of that stuff actually just got shifted into git core and so now they a scaler is just a wrapper around that in the in the git for Windows binary um but everything's baked into git and you can use it on any on any system so now it's just all in git so what is that so there's a a couple things one is pre-etching which I talked about with get maintenance if you run get maintenance start every hour your system will fetch from the server whatever project that you're on it will not update your references so it won't actually do what it does when you do a get fetch in in that origin main updates but it will get all the data and it will keep the references to that data so that when you go and you run get fetch that it's not getting almost any data it almost it always seems to me even if you haven't fetched in 3 days if you go and you run get fetch it's going to be like yep I I already have all the data it's essentially in noop here's your new reference right and so it just makes get fetch seem fast because it's doing it every hour in the background all the time um you can look at this if you run get maintenance start and after an hour you go and you look at your references you look at you know the the sort of forh ref just list out all the you can also just list.get refs or whatever um there's a new thing called prefetch all of the git commands ignore this very specifically so if you run get log D- all it will just 100% pretend that these don't exist which it won't do for any other refs um but it pulls all of them down so that it doesn't GC any anything that it pulled down and it just does it in the background it just makes fetches and pulls very very fast um the next thing that they do is something called commit graph which also get maintenance will run for you and will will build for you but let's look at an example of a large repository so this is the Linux kernel um if I pull down the Linux kernel it has 1.2 million commits if I run get log D- graph-- graph is a little bit difficult because it has to walk all of the objects in order to figure out how to render even the first one right so it has to walk the entire tree because it doesn't know what it's going to find to be able to show you sort of even the beginning of the tree so it it tends to take a really long time it can't incrementally do it um but you can run get get commit graph right and it takes a while but it is incremental so it's only the first time and then it can kind of add to that um and then you run it again and it takes almost no time right because what it's doing is it's sort of caching an index of all of the commit objects so that it can do commit operations or commit graph operations very very fast now you don't really want to go in and run get commit graph right all the time um but there's two different things you can do one is run the maintenance thing that I talked about which will do it automatically the other is this you can set this fetch write commit graph and it will write it on fetch so every time you kind of get new data it'll it'll write the the difference uh update and then all of your log operations are faster if you have a Bigg repository the next thing is file system monitor um so you don't have to do untrack cache that's just caching untrack files but FS monitor if you've ever run git status in a very very large repository like chromium or something like that if you have 400 500,000 files it takes a really long time right because the way that git figures out what has changed is it stats every file in your working directory um and that can be relatively expensive so um FS monitor instead launches a Damon that looks at the file system and watches for inote events and updates a cache in memory that says this file was changed because I saw it get changed with my file system Watcher um and so if you set that that config value then the next time that you run gtit status git will notice that the thing is running or not running and if it's not running it'll launch it and then next time you run get status after that it'll be very fast so this is a status on the chromium project on a on a bare checkout which is again 470,000 files and it takes 10 seconds right so if every time you ran get status it took 11 seconds it'd be a little bit annoying um if you turn this on and you run get status again it's still relatively slow but the third time you do it it's very fast because now it's just running it out of the file system watch room so again if you have a really large repository you can turn on the file system watch room um these are some sort of fake statistics that GitHub did where they did synthetic uh loads of a million files in 2 million files and it just gets worse and worse and worse to do add and Status commands but with the file system monitor it's very fast okay thank you and last is partial cloning so if I clone the let's say the the Linux repository um it takes a while because it's 4 and a half gigabytes if I say filter I can filter out blobs so it downloads everything except blobs and uh so all of those are left on the server but it downloads all the commits and trees and it has to do two different fetches for this one is the gigabyte and a half of commits and trees and then the other one is the 243 Megs of the working directory blob so that it can put something in my working so just takes the data I need for the very last commit um but I can still run graph operations and and all of that um or I can say no trees and I don't know why it's blob none but tree zero um but you've used git for a while so you understand um and that just doesn't bring any trees down either it's relatively rare to use this except for in CI build type stuff but if you want to take a really large repository and make it make it so that it's a relatively fast download like if you're working on the Windows repository or something like that what most people will do what Microsoft does is they filter out the blobs they do this this bloess one um and and then and then git will automatically get new data as it needs new data right so it's almost like a virtual file system um and again this goes down to two seconds instead of instead of uh what 40 four minutes four and a half minutes right um the the bad part is that if you blame it doesn't have all of the data for every Bob file and so it needs to fetch it on demand as you run a blame so instead of a blame looking like this it goes like this right so it just keeps pulling next versions down in order to run the blame so if I look at sort of the difference um a blame from Linux on the full checkout is 4 seconds on a file and and on the blob bless one is 45 seconds so it it it does slow some stuff down and there's a lot of other stuff if you're really interested in large repository stuff there's multipack indexes there reachability bit Maps there's geometric repacking GitHub is has talked about a lot of this have blogged very well about a lot of this if you're interested in it but it tends to be you have to have huge repositories and then the last thing that I'll talk about in the big repo is monor repo stuff which is sparse checkout so how many use a monor repo at work or okay okay not bad not bad thank you for the data this is helpful um so sparse checkout is you can clone with no checkout and then say here's the directories I want and only those ones also you can say I want a sparse index so only they go in the index and if you have a ton of of subdirectories and you only really need to work with three of them you can say give me my just my commits and my commits of my trees and none of the blobs and just check out these this one directory these five directories or something like that and then just grab the data as you need them right and it makes really really large repositories much much easier so another example we have get get status it takes you know five seconds uh and I run this git sparse checkout and set build and base those are the two subdirectories I want in my chromium build and then I run get status and it's much much much faster because it's looking at much less data but those are the only two that are in my working directory as well and when I do commits it looks like the rest of the data is there right like it doesn't pull them out but I can just work with Sub sub subsets um and it even tells you I'm I'm only working with 2% of my track files okay last thing uh on our agenda actually I do have one one secret thing um real fast um but GitHub stuff so there's a bunch of GitHub stuff that you may not know about there's allowed merge types so if you go into your GitHub settings you can say I only want merge commits or I only want rebasing and then you get in a conversation with your co-workers and you fight and like people have actual physical arguments and you figure out are you a rebase shop are you a merge shop um where we're having beers later so if anybody wants to have that argument with me I'm more than happy to do that uh merge so um um and but you can also do squash merging which is arguably a good sort of middle ground for this as well um and set all these things and then when you go and on GitHub you can you can now sort of make sure that your repository sticks to that right so you can say enforce these standards when you hit the sort of merge button it will only give you the options that you have allowed it to give you um but if you try to push say a merge you can tell it I don't accept pushes with merge commits or you know however however you actually want to do it you can make GitHub and force a lot of this stuff now um which is kind of cool I actually didn't know that until recently um you can also Auto merge so if you guys ever uh if you turn on this this uh requirements for some sort of status and you have some CI okay uh and you have some CI and you say allow autom merge there's a button that says I will merge it as soon as it passes CI but it's kind of nicer than going back and checking status and merge merging it later um so I use this all the time um there's also merge CU which if you have a lot of of commits we'll kind of stack them all together and merge them at once um there's require a linear history if you really like rebasing you can force GitHub to not accept pushes that have merge commits in them um you can require signed commits which goes back to the SSH thing and so on and then the last thing on GitHub is the PRS that have heads so if you run G LS remote on GitHub repository all of your PLL ests actually have refs um that you can pull down and you can merge from most people don't know that most people think you have to add like if somebody sends you a pull request an open source project that you have to add that as a remote and fetch from that and merge that in but GitHub actually advertises all of these refs um that you can pull from or or fetch from directly which is kind of cool so you can put in something like you know give me all my pull requests as actual refs and and then every time you fetch it'll it'll pull all of those down as local references which is cool okay and then very last thing I wanted to talk really fast about git B which is something that that uh I'm working on with my team over here which is we have this new thing called virtual branches so we can work on multiple branches simultaneously instead of having to sort of stash stuff and switch branches um and so you can have sort of each lane is a branch so this is one branch and another Branch maybe a bug fix like you're working on a feature and you see a bug fix you don't have to commit it into the feature Branch right you can kind of and you don't have to switch you can drag it over to another Lane and it separately um and each one can kind of go into its own PR as though that was the only thing on disk but it's a very kind of nice way of working um and uh it's open so if you go to to to to GitHub um you can take a look and and see if that's something that is interesting for you and that is the end of my talk thank you very much and let's drink okay so I wanted to uh have some time for Q&A if there's any questions or or something that I can do there's a question over here yeah so uh since you mentioned you do merges I cannot help asking this so uh what about rench diff does git git Butler does it and why does GitHub not do it um why does GitHub not do get range diff um so I almost put a thing on Range diff in here but it's a very kind of specific workflow where you don't use it unless you're doing a lot of sort of rebasing series and you want to compare sort of a rebase series to another series to see if something changed um so yeah if you if you do that check out rang diff um I have no idea why GitHub doesn't do that except I think that you know GitHub like a lot of services like they try to say here's what we think a a a workflow should be or what a good workflow would be and they build tooling around that and try not to do everything that that could Poss like like every workflow that they see in order to try to make it less confusing for people so I think it's more that people in GitHub don't use that type of workflow like like at least when I was there I can't speak for the last you know eight years or whatever but like we did not do a lot of rebasing we did a lot of merging and so if you're doing merges all over the place then you don't need range diff like range diff doesn't really make sense in that in that workflow because you're not comparing you know what is this this patch series compared to this patch series and did I miss something is that's my guess is there another question we've been working a lot uh in my team with the Sub sub modules um and frankly um it's not a nice thing to work with uh Google has for large project projects introduced repo um but is there any like work that you know of is being done on sub modules because um keeping track of refs uh of updated Sub sub modules is frankly yeah yeah it's a great question uh why do subm modules suck everywhere is essentially the question and that you know it's funny because they always have like I've been working on this as I said I've been in involved heavily in the git project for more than 15 years probably and there's not a single even Meetup of git developers where they're like we shouldn't have put sub modules in there like they it's it's and and there's a lot of different reason I think what a lot of people are moving towards is monor repo which is is Monaro stuff where you just have everything in one repository so you don't have to to worry about a lot of the things you did sub module stuff for but it doesn't cover every case and even actually a lot of the stuff that I talked about like the the sparse checkouts and and the sparse index stuff I think don't work well if you have Sub sub repo uh sub modules because just nobody uses them that works on on git and so they they don't optimize optimize anything um but yeah I I I honestly don't know from from a the companies that I've talked to in the last couple years most people that that care about that either use P package management type stuff for that that type of problem set or they have a monor repo and and they can start using some of these tooling although github's not good at monor repo support so that that that becomes the problem now right like locally it's fine but now all your issues are in one repository and all of your you know yeah but yeah hey thanks so uh with this SSH signing is it possible to specify more than one key yes okay yeah yeah you can I mean what when you're signing it or verification like the key ring uh when you're signning I mean you have to choose a one to sign the commit with if that's what you're asking but you can is that what you're asking I don't know what you're asking yeah okay so my question would be why can't force with leas be the default Force yeah I mean the the thing why can't force with leas be the default I it it probably would be a good idea or or to have the more aggressive version be the the longer option I think it's more just that git is always Backward Compatible right like that that's always like like for for 19 years now there's like almost nothing that I could do I could have scripts that I wrote in in 2005 they would probably still work with with with the current version of git and it's a great thing about git right like it's actually very very nice that they really don't deprecate very much um and they they make sure everything's always backward Backward Compatible that it gets into trouble there's actually stuff I didn't really talk about like there's like get switch instead of checkout that's that's closer to just being able to switch branches and not do other stuff like like uh like revert file contents and things like that um so they kind of add more to the user interface in order to try to make it less confusing but then there's just now more commands that do you know overlapping things so um but yeah that it's it's because they don't want to be Backward Compatible on anything and they just assume you're going to set up aliases for new stuff that's cool I think in that case it would be great if it would be configurable over uh so sorry it might be I I'd have to check if you go to like the get config man page there's 10,000 things that you can configure it's it's might be possible I don't know if you can overwrite what force does to force with lease by default um if you actually push put it on the command line um but you could probably change what the default uh behavior of get push with no option is right but that's not usually what you want to do so it may be diff there may not be one I'd have to look or you'd have to look actually you look yeah um thanks for talk and first of all uh git squash no other options are allowed but my real question is um if you are like back at the git development team what would be the direction that you would like to see get moving more like we have a lot of features for monor repos what are the things that you think get is missing ah what a great question I mean to some degree I have a little bit of a cheat in that I'm writing a git client uh and so everything that I'm putting in the git client is stuff that I kind of wish git did so I would like to be able to work on more than one branch at a time without with and being able to to essentially have more than one index and more than one head that I'm working on simultaneously I think I mean we're building that and I find it very valuable so that is one thing um the other would be uh recording everything you do um that it's a little bit frustrating that I can lose work in git but I can't lose work in you know Google doc or something that just records all the like just save a crdt of every file all the time like how expensive is that right like it'd be kind of nice to say show me what my working directory or this file or something look like on Tuesday at 10 p.m. right like you can't do that you can't it won't save anything you don't commit really right or stash which is basically commit um but why not like there's no there's no reason for a modern Version Control System it's not it's not network based it's not disc bound right like just save everything it'd be nice to just say watch this rep like watch this directory and make sure I never lose anything in it and help me craft commits when I'm ready to share so those would be two big things that that we'll probably I mean we've built both of those to some degree but like even in core git I think it would be nice to have to have there there's git hasn't changed it was written for people that are that are submitting patch series to mailing list right and it's very very good at that and I think GitHub kind of bastardized it a little bit to really go towards the poll request rather than than talking about patch series and have having Communications over patch series which has a different set of of of strengths and weaknesses um but like I said it's not it's backwards compa it hasn't changed really the user interface fundamentally for which is why a lot of you guys didn't know a lot of the stuff that I talked about right like you you just use the same thing all the time I just use the same thing all the time so um so yeah it's it's it's a little bit difficult to go in a massively different direction for for those reasons I think but there's lots of cool stuff we could do with Version Control I think okay one one more maybe how how much time do I have yeah one more so um we all love the command line but one question do you ever use any visual tools do I use visual tools um so I use obviously I use GB I've been using it for three or four months now um which I I enjoy a lot the from and I use you know Visual Studio code with Vim key bindings because I'm kind of a nerd but then also not um but uh I'm I'm partial partially nerd partially executive so I have to do Visual Studio code with key bindings but um but before that I think is a more interesting question which was what did I use what I mean what do you guys use goys versus the command line I used uh goys always for interactive adding because I just find it much much faster to do interactive adding through almost any guy than it is through the the actual interactive ad script that the git provides um I would love to do rebasing more drag and droppy or or something like that but you know I I can also edit the stupid script and you know put put pick and stuff all over the place um that's but but for the most part it's interactive adding that's the thing I spend a lot of time in and when I do it takes it's worth a contact switch to go over to a guey and say I can make this much faster and much more specific than trying to go through you know like hit five to choose the next file grouping and and and add them and stuff like that so it's really it's whatever's fastest I think everybody uses the command line with Git still because not because it's it's the best thing that could possibly be because but because it is fast right in almost anything you do it's faster than hitting a button that then calls that script right and so I always use the command line for stuff unless it's something like interactive ad where really having a gooey adds something to the experience in a way that makes what I'm trying to do faster okay that's it uh hopefully I'll see you for drinks later thank you very very much it's been a pleasure bye w

Channel: GitButler

Views: 950,247

Keywords:

Id: aolI_Rz0ZqY

Length: 47min 0sec (2820 seconds)

Published: Thu Feb 08 2024