 My name is CJ, I'd like to show you a little bit about Git config, which the main reason for this particular talk is every time I go to a new machine or a new, when I'm doing a program with a new colleague, especially a new engineer fresh out of school, usually Git is not being taught in school, and you start off with a brand new installation of Git with no configuration at all. And without configuration it's pretty hard to get anything moving forward, like you get no colors and you do not have the shortcuts commands which I have built over the years to get it. So I'm going to go through a very step-by-step like some of the Git config that should be ideally defaulted in most places except it's not really always the case. There are a few ways of doing this, of course you can always create your own .file repository which you can contain all your previous development environment configuration. So Git config can be one of the .file stuff you store in your .file directory. Who here already maintain a KITGAS .file directory? Come on people, you have to use .files. Can you tell us a bit more about what .files are and why they are useful? Okay, let's do that. Google .files. So Git up has created a repository called .files.github.io. It shares a few favorites and they are mostly batch and they are essentially good. There are a few examples here. You can take a look at them, you can choose which one you like most. Usually the one at the top is more popular and hence they are top. There is only one batch one over here if you are old school and you still want to use batch as opposed to .files.github. It's the only one that has batch .files, every few players uses .files. I'll give it just open a few examples to show you. This is what .files look like. It has .batch profile, batch RC, editor config, Git config, you know, Mercuro as well, screen RC. Who uses screen in these days? No. Thank you. If you use batch, then apparently that implies that we use screen. What's wrong with batch? Is it defaulted in websites? It is defaulted in websites. It's a matter of if it's services or school, you know. It is both. Sorry? It is both screen and team apps. You use both screen and team apps? Yes. The reason you don't use screen is because screen is not in actual development anymore. It's kind of the stagnant project that nobody does in batch fixes. It's not maintained anymore. That's why you shouldn't use it. This one is .files. They usually maintain it in a Git directory. I can show you mine as well. Mine is different from those. This .file is actually very whole. About five years. The very first report that I created when I started using it. The first thing I want to do is I want to store all my Git directory, sorry, all my .files in the Git directory somewhere. This is for them. Most of my .files are inside the directory. They're very tiny and small because I try to keep them tidy, like doing regular screen training, editing all their batch lines and batch profiles, and the stuff that shouldn't be polluting your batch environment. Now back to the Git topic. How do you do that Git summary thing? It says, summary is not a command. That is a Git extract. Sorry? I've seen that sit back before the report. There is an extension called Git Extras. This is Git Extras. It calls itself also within this. It has a whole bunch of tools that you can use. I just scrolled down very quickly. This was created by TJ Hulliver at first. It has grown crazy over the past few years. There's a lot of new commands that you cannot, which really you do not need. The point of this topic is not to cover the stuff you do not need. They are useful if you know what they do, but you really do not need them, except for the first one, DLIS. DLIS is pretty cool. Summary is one of these commands. There are other command line tools, like Hub, for example. Hub. Okay, I'll show you Hub. Hub is a GitHub-specific tool. It's a command line tool. It extends most of Git default functionalities. More importantly, it's meant to use, it's meant to let you use your command line tool to integrate with GitHub. It's very, very, very specific. You do not need it, but I find myself using it a lot because I like creating full requests from my local. There is a full request command called Git full request, and you can specify any messages you want and title the message description and create a full request for you. You don't even need to go to the web browser. This is still popping. Let's go back to Git config. The very, very central Git config should really not contain too much stuff. Obviously, you need to have your username and email. I don't know what this does, but I see a lot of people using it, so I'm just going to add it in first and then I'll figure it out later. It looks like something related to GitHub, so I'm just going to talk about that there first. Call exclude files. Exclude files is where you put your Git on. I have no idea why GitHub doesn't have this default. You actually have to specify it. You can add it to a software home. This is just a convention. You don't have to run a software home. So you're encouraged to use this local Git instead of storing all your project specifics into the new repository or adding them into your individual registry. Analyze, line feed, or to see if it's false. You only need this if you are using Windows. Otherwise, you don't really need them. Anybody using Windows here? Wow, that's cool. So right here, color. If you can take this down, copy this everywhere. You can actually add this into the ETC Git config in the system-wide config because, seriously, who uses a terminal that doesn't support color details? You do? Wow, it takes so much. Okay. Push before. So since Git version 1.8, I think, is it 1.8? So 2.0. 2.00. You start seeing this warning that says, do you want to use the old method of pushing or do you want to use the new method of pushing? The difference between the old method of pushing and the new method of pushing was that the old method, they call it matching. The way matching works is it takes all your local patches and it finds all the remote branches and for everyone that the names matches, it pushes everything to the local to the new one. This may not be ideal if you are a beginner and especially if you're like me, you like to work on one branch, switch another branch, work on some other features, then decide that you want to push your current branch code instead of pushing everything else. I would recommend using the simple one which is why they introduced 2.0. The old school, for Git users that I have been using Git since version 1.4, always they have gotten used to the matching style so you tend to find people putting in matching here instead of simple. If you're new to Git, always use simple. Stay simple and it will make your life a lot easier. What does it actually change? What's the difference between matching and simple? Simple only push your current branch, matching push all your local branches. You do not want to push all your local branches most of the time, especially if you're still working on some and it also depends on what is your habit if you have a habit of commit push, commit push, or you have a habit of commit, commit push. Does anyone understand what that means? Okay, awesome. Bash upstream verbose. This is a built-in functionality. We don't see it most of the time in the most environment. So depending on how you set up your prompt, your bash prompt, the SH has something similar as well I think it's what's it called? Bash prompt. In your bash prompt, if you put a command like this, can anyone see this? This is prompt one. And I've had this... Okay, so this is my bash prompt. It's relatively complicated because it has colors in it. You don't really need it. You can find it somewhere inside here. There is a soft shell that opens the soft shell and calls in PS1. With this one, you can... You will show this section here, this master thing with... So this basically allows... This shows you what state you are in in your current directory. Currently, I am branch form master and this symbol means that I have untracked files. If I add a file, you start seeing a pass, and that pass means that there is a file as being stage. So when you run git status, you will see that a file is stage. Once I commit it, it will disappear again. If I make changes to the .git config, it will show a star, which means that the directory is 130. So this is the verbose part of it. You do not need it, but there is no harm putting it in. And if you do, use the git default platform verbose function. Be careful when you are using this as well. The underscore and slot git, underscore ps1 takes up five of our resources. So if you are... If you notice, there is a lot of delay. Each time it is being executed, it is relatively slow. If I turn it off... I do not remember my command, so just see it. So this basically turns off the verboseness and the response time gets improved. Okay, let's move on to the next one. Div. No prefix. Have you ever run git-div and then you want to copy the file? So this will print the patch. And if you do not have the prefix enabled, you will get something like this. With a prefix a slash, a big b slash, that would be perfect. It is relatively annoying because I have a way to just double click on the file and then I can copy that and use it somewhere else. So I tend to not have that. The other thing that concerns me is that with this same hash, if you generally push it to a file, you can actually reapply using the hash. So hash-g0. So if I would paste it like this, it is pretty annoying. So I have to scroll all the way back with the hash-g. Okay, sub-module. Do I have an example? So I have sub-module in this report and when I run git-div, it will show me the log differences. So there is a sub-module called mid-sdk and it will show me the log history. If I don't have the denominator, I will not show you this. Next one, grab. Line number is true. This basically creates the line number when you run a grab. So git has a command called git-grab. It searches all the index files in the local directory and it is supposed to be faster than silver-like, sorry, silver-surfer, ag and ag. Does anyone use any of these tools? Okay. Which one do you use? Aged. Aged. Yeah, git-grab is faster than ag. Apparently. Aged is faster than ag. Ag is faster than grab. Yeah. Git-grab is faster than all of it. The only reason is because git-grab is indexed. It searches the git internal index. So I want to find something like prefix. What would you think of this now? Oops. Oops. We'll show you the perfect line number and you might want to alias it to something nicer. So you have something that is more real. And grab supports all most of the grab options. So you can do contacts, for example. And if you do C3, it will show you three lines before and three lines after. So this is useful for debugging and searching stuff. Yeah. So if you set a line number true here, it will always show something. Much locked through. I forgot what this does. Okay, I remember. So when you do a merge, Git will ask you to enter a coming message. Right? If you have this option on, it will automatically look through both branches at their history and automatically populate the long messages. So this is very useful. So let me see if I can find an example. Let's say in underscore, I want to... Okay, there's too many branches. I'm trying to do the casing. Check out the casing. Sorry? Okay. So right now, here it shows me U minus 11 means that I am... 11 commits behind upstream. upstream refers to the original status master. This depends on how you set up the bunch to try. Usually it's... I need to know how to turn that off. Git, merge, async. What is this? Don't you remember this? Okay. Async. So I don't have async branch checked out. So... Okay, I really have no idea how to turn this off. Can you like... Valentine, can you like tell Bob to stop? Yeah, that works, right? Okay, yay! Okay. I don't have async branch to replace so I need to do pre-fix it with the remote. And when I do this, it says complete. Awesome! This is like freaking awesome. Anyway, the message is constructed. You can find it in... What is it called? Git, everything. Okay, here we go. So this is the message that it constructs. Let me try and see if I can... Show you the whole thing. Yeah, this is the message it constructs. It has all the... Well, some of it, the last... It also shows you the conflicts. Now... If you are familiar with how coming messages work, anything pre-fix with... The hash will be gone. So you can choose to keep this or you can choose to not keep it. So it shows you the... history of whole bunches, depending on which one is the... the one that's trying to... So if I do add all as you suggested, just basically... committing everything that's broken. By the way, did you notice this? This is the first conflict, but it shows me... what I'm trying to do right now. It also shows me that I'm still... I have at least time, but it also shows me that I have to stay fast. This is pretty awesome. So default git... Functionality, you just need to add it into your... your dashboard. Git status. So I have the files here, they're all conflicted, and I do a git commit. When I do a merge and a resolve conflict, I do not need to specify the dash and messages because it will just automatically read it from... the merge and a resolve message, the one that shows you this now. So there you go, it comes up. This is what it looks like. Does anybody read this... this section here? Has anybody read it ever? Awesome. This is like design fail, UI fail. Okay, so... I'm gonna save this, and I'll just show you... this is the git commit history. So the merge log will show you this one that says this. Now, come down to aliases. Okay, aliases are tricky because everybody have their own preferences. Everybody prefers to use different commands and short form for what they prefer. Here, this list here is by no means any recommendation of... in any way because the short form is really hard to decide what it actually is. Some people prefer co2 commit instead of checkout. Ct is relatively... it's mainly because it can mean copy as well. How do you do a re-run git ct? Does it mean charity or does it mean... What you definitely should have, for sure, is LG, a short form for a log graph, online, and everything. Every time I go to a new machine, every time I need to look at git ct, that's the first thing I come up with, like log, dash, dash, graph, dash, dash, dash, dash, color, it goes all the way. Just to see a beautiful git history. Just... I think everyone should just have this as default, and then maybe a dash, dash, as proposed for the default git logs. So my git log is still the original ones. The long... with the long hashes and all the stuff that we mostly do not have, as opposed to git log, like this, like the beautiful git history. The underscore is not helping very much here. So you can see... you can see which pull request, who is the person that committed, how long go, and how long to go, and short hashes, and you can follow the commit history line to see what's going on. And yeah, that's it. So I have three more. Rebase, this is my favorite. This is brand new, by the way. Other sash came out in 2.2. The squash... This came out in the version 2.2, I don't know which version, if you can do a quick search on this, on GitHub, to find out when this is introduced, on the involvement of the grid. Otherwise, it doesn't really matter. So on the sash tool, basically what it does is, if you have a habit of rebasing, you do... and especially if you're working on a feature branch, you're hacking away your code, and then you realize that, hey, I just push it, can you go and rebase it? Then you, like, go and rebase it. The general habit is, you run git sash, then you run git rebase, and then you run git sash call. Auto sash just does it for you. So when you run git rebase, you automatically send it. You can also use auto sash as a function. So, for example, git rebase the sash auto sash. So this will work as well. The same applies to auto squash. You can also do git rebase, dash dash, auto squash. Now, auto squash is what you use if you are using what you use to fix up. Does anyone use fix up for? Hey, one percent. Does anyone want to know what fix up does? Or is this too advanced? We rebase sounds pretty advanced. It's rewriting history. Some people are not comfortable doing it, like Deepang said. We work in the same company, but I have completely different philosophy when it comes to rebasing. Set will show you the difference between before you do the rebase and after you do the rebase. So that's useful when you need to do something fun. I'm going to give you an example just by taking this same underscore report reset our origin master. So I'm restarting my head to master. If you notice here it says when U equals U equals means that I am on par with origin master. My master is the same here as origin master. It can prove to you by running git log and if you see that and my head is pointing to master origin master is in the same location and origin data is in the same location. Now, we try to check out async. If you notice here we set up a new branch and set up a new branch async origin so and then it switches me to async. Because I don't have a branch here in my local. Now I want to rebase against master. Who here passed that that's really a conflict apart from you. We're going to have conflict for sure because usually a merge will resolve a conflict opportunity for you. Rebase will not do anything to you at all. It will just it will just be over. So rebase master practice. So my first conflict. Again, if there's one who showed me some stuff here I'm tracking her 30 directory some state files and tell me that I'm trying to rebase. So it tells me that I have 26 years ago and my conflict happened at the first one. I'm going to be lazy and I'm just going to add everything and continue. Rebase continue. Again, no, no, check my way away. Okay, it's done. No, it's not like that. One more commit to go. Done. Okay. Yes, okay. This is where I will start with. When you run the rebase master and you're showing the data to go to and those tiles are there so you can pass for it. So this is the stack that it fits on. Okay, cool. That's about it. The rest here is just convenient functions that you can choose to set your local after record is just github loader Okay, any questions? Okay, I need to cover one more thing. Where to find your githconfig? Each system will have multiple githconfig files and depending on where exactly it affects it. So there is a system-wide configuration file. Then there is a second user configuration file which is usually I think it's Windows base. I've never actually seen it before but it's convention. What's xdg? Does anyone know what's xdg? X. So if you notice here it's storing it in docconfig. It's actually that config. The docconfig convention is not I am not very familiar with it. I don't see many system users in docconfig. Then there is your own so tilde means home directory and githconfig means your own custom global. Anything that you saw in global you will be saw there. The last one is VEPOS C3 specific configuration file. For each custom registry you can also you can find them in in the gith directory. This is where I saw stuff like which is the remote branches packing and what other remote give you a clue. I use gitconfig sometimes to solve antiviral variables. Not recommended but you can do that. That's about it. I will push this out to github and you guys can copy I guess. You can find the git in github as well. I will be pushing it. I will copy this from some other boilerplate. Thank you. We have one more exercise which is for