Hey, quickly checking the sound, is it working? Sound and clear. Nice. Any echo or something? Didn't hear anything. Okay, good, good. Yeah, that was I was curious about because I am like always messing around with my audio video system all the time actually creating new set of videos for a new bootcamp. The new bootcamp will be data focused, so it's data driven decisions. In January timeframe, I will announce it, but some of us are actually busy creating video material for that. And so that's why I keep toggling my audio settings every time, so I had to ask this question. Cool. So did you get a chance to watch that video that we had the other day about what was that? Four year old? That's a funny video, but it's a very nice and accurately described video. Let me get some noise going on outside. And so Git for four years old is a fascinating video actually, if you ask me. So now what I intend to do is ask you this question. Hey, did you watch it? Which is one of the questions I wanted to ask. Did you get a chance to watch it and did you find it useful? I have a question right now actually. Okay, okay. So since some of you have not watched it yet, what I would like to do is just begin with a brief overview before we jump into the exercises. And that is what I intend to actually do. So I am starting my desktop share, which should bring up the terminal on one hand. And on the other hand, I will bring up some kind of a writing notepad so I can describe the concept and then actually execute something like here. So this is the notepad going. Come on, there we go. And the pen. Okay, it works. And on this side, we have the terminal going with the Git command all set up to use. Oh, it's not set up to use apparently. But why is that? Yes, I think I made a typing mistake. So that command actually is installed and correctly loaded in your virtual machine as well. To use Git, you don't necessarily need a particular operating system because Git, as you know, is the product from... Sorry about this. I have a visitor and my dog is going nuts. So what I'm doing is ignoring him for now and somebody will take care of the dog. So we are looking at the original product called Git, which is what we intend to study focus today on. And the download is available for multiple operating systems. There is a Mac build, Windows build, source code. And you can build Git yourself if you like from the source code and all that. But if you go to the source code, the source code of Git is on GitHub, like here. And that's where people can actually get the source, compile it, build it, and create this binary that we are talking about. Git, that's the binary. So that's how this is actually... The product started a long time ago when Linus Thorwald wanted to create a version control system. It's basically a version control. And you may have heard of or used version control systems of a variety of different types. Give me some names of things that you already know that you use as version control already. Some of you may have used TFS or Microsoft. What else? Clearcase, SCCS. Yes. So there are lots of things like Perforce. Maybe I'm missing the name here. Let's check up the name. But this Perforce is the original product based on which Microsoft has its own internal product that Microsoft uses internally for Windows, which is called Source Depot. And that's the internal tool that Microsoft uses. At least they used to use Source Depot when I was there. And this is a derivative from Perforce. So variety of source code control systems exist, but this is the king or queen, whatever you call it. So this product, Git, turns out that it is so immensely useful and popular and across the board, developers in every different type of operating system actually enjoy using it and that it has gained this status. That is very clear for a variety of reasons. And one of the most surprising ones that you will find is that Visual Studio now supports Git natively. So here we have TFS like Git. Git is natively available in Visual Studio starting some years ago, and Microsoft is slowly adopting Git across the board in all their products internally as well. It's a major victory for open source, as you know already. And so many of these other choices are also pretty darn good, but somehow the community is accumulating and working and focusing using this. And using that software, companies like GitHub and Bitbucket and GitLab and many other service providers, they have come to create services. These are services that people use. And so we actually will use a GitHub as a service today. And I will create accounts for you in our private area if you want to play with the private repositories as such, which we will get to. But let's begin with a quick short understanding of what exactly Git can do for us from a management perspective, from a source code control perspective, from a perspective of managing state. State of what? It is not state of Texas or state of Washington, but state of something else. What? It's the state of our business, if you will, generally speaking. It's the state of business you can maintain in some sense inside a collection of things that you want to put in a properly organized structure, which can mostly when it is dealing with software business. That's how I tend to think of it. It helps you manage the state of the business. And in business, you can have multiple aspects of it, from marketing, sales, to development, testing, QA, which is testing again, program management, product management, all these aspects that go along, servicing, support, all these things together constitute business activity. And so as long as we can put and manage the state of our business in some systematic structure, in example, a folder structure. And in that folder, whatever we put, whatever we have multiple subfolders, and then underneath them we have more folders and then files like that, whatever structure we put together and the content that goes inside that state of that entire thing. That state is managed by Git. That state is managed by Git. That's the broad usage that I would like to talk about and then show you some examples. So here I will actually begin with creating a very simple product, very simple folder structure. I will call it, you know, let's call it MKDIR. Let me make it big. So making it a little bigger MKDIR and we'll call it using Git. That's the folder I created. I will go inside it and then I will list out what do I have in that folder. I have nothing. That's good. You can see it has nothing. So, by the way, is it true that it has actually nothing? Yes, it does not have any absolutely nothing at all. In that empty folder, my current state is nothing state. I have nothing. There is a question on chat. Let's see. Only about 60 minutes. Yes, we will stay focused on 60 minutes and we'll finish it off quickly before we run over. We will not go beyond six. So we have 50 more minutes. So let's stay focused. The state that we currently have in our folder called using Git. That folder, the state is empty. It contains nothing, right? Great. Now, let us look at creating something in that folder. But if you want to actually manage that current folder using Git, that folder, if you want to manage that folder in Git control, you want to put that folder inside in the control of a Git repository, which we have to initialize Git in that folder, like with dot mentions that, you know, please initialize Git in this folder. And so it just did. Initialized empty Git repository in the folder. So now we have initialized the first step. The next step is to add everything we have in the current folder to the Git repository. Now, this is a two-step addition process like databases. Also, you have this idea of a Git add followed by Git commit. So it's a two-step of processes that we need to follow. We have nothing in the folder and we are doing, you know, this step of initialize. Then we'll do add and then commit. So these three steps, this is like a one-time only operation, one time. These two steps basically say, I want to add these files into my Git repository. And then, yes, I commit. Please do so. And so it just puts a commitment or a commit stamp on that particular addition. Sometimes you want to remove also, removal is also possible. So those scenarios that we want to play now. So what I will do now is... Okay, Paul, I get that. I got confused. So, yes, I meant that I watched the 60 minutes of the video. That's good. Thank you. So this add, remove followed by the commit operation. The idea is that we are actually doing this two-step process to incorporate some file, some folder, some state into Git. We are basically putting the state into Git repository control. And so that's what we intend to do here, which is Git add. Everything I have in my current folder, which, by the way, we have... I broke it, by the way. I broke it. I did not do it. So I would like to show you that we have nothing except this new item called.git, which has been created because we initialized an empty repository. And that is what this thing will store all the things we needed to maintain, manage the state. We know we are managing the state using this Git initialization, and we are adding, removing, and committing. That transition of state, all of that information will be managed under that folder called.git. And it is a hidden folder. If the folder goes away, everything goes away from Git perspective. Whatever you have in the file structure will stay. But if you delete that particular folder, then that Git control goes away. Nothing else is stored about this folder anywhere in the computer. It's only exactly in that folder called.git. That.git folder by itself is pretty complex. You can see what it contains. It has a head, configuration, description, hooks, some other commit, post-update, pre-apply, pre-commit, pre-release, this, that, info-excludes, info-objects, references, heads, and tags. Lots of details available inside the.git folder. We can see them, but we don't need to actually venture in there because it is managed by Git software. Having seen the content of.git, we would like to see what we have in our current folder. Apart from the.git, we still have nothing. Good. Now I want to actually make sure that we begin with an empty state. Our current state is empty. I want to add that empty that I have and commit that empty that I have into Git. I'm adding empty, committing empty, so I will have empty state recorded. I will do that right now, which is here. I will like to git add dot. What you will see is that now my Git status changes in my initial commit. It tells me that I am on a branch called master and my initial commit is there. It's ready to happen, but there were no files. It did not actually add anything because it did not find any files here. Apart from.git, which is its own control, it did not find any files, so it did not have nothing to commit. There is nothing to add, nothing to commit. It will do nothing. It just ignored that command because there was nothing to add or remove. The state was empty. The empty state you cannot really add or commit because there is nothing. We want to actually create something. To create something, we have to create a file, for example, or a folder. That's what we basically create, write file, folder, links. That's what we can create. We will begin with a file. Let's create a file right in this location. We will create a file called A. Now we have a file called A and that is our state. The state is we have a folder called using it and it contains a file called A. If you see the old thing, we have this file called A and the folder called.git. That's what we have currently. Now what I will do is add and commit. So git add everything in my current folder, please do. It did, it added something. You can see that the sign changed from a square here to a plus, something ready to be added, some notification showing up here. That's something ready to be added. We can also see git status to show that, you know what? Here we are on the branch called master. In the initial commit, there are changes that need to be committed and those changes are a new file, green color, A. This file needs to be committed. So what we are essentially doing in that two-step process is that we have this add process and a commit process. In the add process, we basically take this file, the A file and stage it. You know, this is the candidate that I want to actually commit. So it's a stage. When you say add, you're staging it. And when you say commit, you're actually committing it. So it becomes a new position in the graph. What is a graph? What am I talking about? Let's see. Think of graph as a wild tree or even forest, if you will. Let's get to the forest part later. But it's a wild, wild tree. It can have multiple roots, multiple branches, multiple leaves, and you can have other trees hanging on to one of the leaves and things of that nature. So it's a wild tree, a crazy, crazy tree. So it begins with somewhere. And that somewhere is it has nothing. So it's empty. So that's the beginning point. And since it is empty, there is nothing to add, nothing to commit. So that's the beginning origin initialization point. That's the platform, the beginning stage or original stage, whatever you call it. But that's the initial thing. And so think of this fictitious tree that is going to build up now. And we will have only one branch right now in the tree. That branch is called master. That's the name by default. So initial is a platform. And then a fictitious branch is going to grow now. We will call it master. And that's the name to initialize with. That's the default name chosen. So on the platform, we now have a random file created called A. And we want to add it. So we are putting that on a stage. So that's great. Now we want to make a... Actually, I should don't denote it differently. I should maybe call it stage. So we are staging this file in the master branch. And when I add it, I just put a dot, dot, dot around it to indicate that it has been staged. Now before, I do not have these dots around. So I just have the file. Now I add it. So I just indicate that it is now a candidate to be committed. And that is what you see here. A new file changes to be committed, not committed yet. There is a comment coming up, which is... Okay, this guy says Zoom link. Okay, I'm going to invite him. Okay, invite by IM, copy URL. And here we go. And who's this guy? Yeah. So let's see if we have... The link is here. And so, okay. So we will have Mohammed also join. And let's make sure everybody is accessing the link. I think we have five people right now. Mohammed is available. Okay. So yeah, let's keep going. So this changes to be committed is this idea that we have this new item called A. We want to commit that now. And so when we commit, what happens is we basically make it a new leaf in the branch called master. So we have a foundation. We just have one item and it's a new leaf. And so let's call this leaf. It's actually in Git language, it is called a commit. That's what it's called. It's a commit and it gets a hash. It's a long hash, hexadecimal hash you receive that you will see. I will show it to you just now. So as soon as I commit this item that we have, this AA file, I will now commit. So git commit. And then there are these flags. Actually, let's begin with just the commit message. If I attempt like this, then there is an editor that pops up. This editor basically saying you want to write something about what the heck are you doing. I have no idea what you want to do. And so you have to write some message here. So I will write, I am going to commit this item called A. And that is my commit message. So that is how I want to write and describe to my team members, what the heck am I committing? So the idea is this editor is saying, please enter the commit message for your changes. Line starting with hash will be ignored. An empty message aborts the commit. And it is on my master branch. Initial commit changes to be committed are A, new file. So I'm going to commit this item called A. That's the commit message I want to add. And if I don't write any commit messages and just exit out like this without saving and say, no, don't save anything. It was basically it aborted that message. The whole commit thing got aborted because my commit message was empty. I did not write any message about what the heck am I doing here? When I am committing, I had to create a little message for my team members to understand what am I changing from this empty state to this new state. This transition is happening. I want to tell everybody what am I changing through a little message. The message can be anything you want, but it is better to write descriptive messages such as, you know, git commit and enter. It opens the editor. And here I can say, hey, this is my first commit. I am trying to commit a new file named A. That's my commit message. And so now I want to actually save it. When I save Ctrl X and say yes and enter, it actually committed a new tag in git. So you can see that in master, we got a new hashtag. It's called hexadecimal commit guid. It's a globally unique identifier that get generated. We'll see more details about it in just a minute. This blue item. And here, hey, this is my first commit. I'm trying to commit a new file named A. And that one file that changed is an indication that I just modified this new file, added it into git commit, and I have no insertions, so no deletions. One file created. And that is what we now see. The plus sign here disappears here. Now we also see git status. Git status we have. It is on my master branch. There is nothing to commit. Our working directory is clean. Let us see. What do we have in the working directory? Just like it was before. Not much change. Actually, not much visible change, but the changes are actually inside the.git folder. Again, we don't need to go there. We just operate on the current folder using git command. And git command operates inside the git folder to deal with whatever we are dealing with. And it is better to not go inside the.git folder, generally speaking. Now we have this file A in control of git. OK. What does that mean? So I'll open up the folder. And we see that in that folder we have this thing called the file A. And what I want to be able to do is that this file that we have A, I know that I am protected. And in addition to this file, I also have a.git folder, by the way, that is invisible. It is hidden. And that is this folder that doesn't show me. It's not clearly visible at all because it is a hidden folder. But I know that this file is protected by git, which means I can just delete it if I like to. And I don't need to worry. I can bring that file magically back. How do I do that? But first of all, let us see what happened to git. So now we have our files missing. In our flag, we see master with a red cross. Something has gone bad. Let us see. We see the lsla. Show me the hidden files. This.ds store is a useless file that Macintosh generates. We don't need to do that. We don't need that file at all in our repository, in our folder at all. But we still want to get this file back. And we don't want this. Sometimes machines generate random things that we don't want. These are the back files sometimes some editors will create. So this is a Macintosh artifact that many people dislike. It is actually quite pointless. So we want to get rid of this. We will do that. But for now, I'm worried about this file that got accidentally deleted. I want to bring it back. How do I do that? Let's say git status. And we know that it is on the master branch. There are changes not staged for committing. Something got deleted. And it has not been added to commit. So we can revert back if you like. You can just discard by using git checkout in the working directory. We can just check out the master branch and revert back. Another way to revert back is to do a git reset, dash, dash, hard. And when you reset hard, it brings you back to the same git tag, the b3bbaaf7. That tag comes back because you just reset it back to the previously known good commit. And so we now have... Okay, I cannot connect with this link from my iPhone. Wait. I've got to give another link for this guy to have him join remotely. So Mohammed is running into issue. So how do I send an invitation to him? Invite. Invite by invitation and send. And so let's see if we can have him join. And what I will do next is... That file is back, by the way. This.a file, it came back because we reset. So we will check our folder listing again and we will see that our file .git and a, this a file is back. It came back because we did a reset. Let us add a couple more files and actually convert this whole thing that we are trying to draw in form of a tree into another commit hash. And we'll add one more, basically one more leaf. So it began here. And we now are going to create another file. And this is all committed. This is a new file. So that I will create a new file now, which is what I will do next. So I will put this side by side. And the terminal better go side by side. That's easier. So adjusting a little bit. And here in my folder, I have the.a file. I want to create another file. I'll call it.b. And so now I have this.b file, which is added on to the folder. Now let us see git status. You see that this.b file is a new file. It doesn't know what to do. It has not been tracked. So we want to track that file by git add command. So we can say git add b and then check the git status. And we can see that this is a new change to be committed. It's a new file recognized because we now track it. It was not tracked before. By adding this git b, we are now tracking that file b. And we can now make a commit. So we are now tracking that file. So we know about b now. Git knows about b. And now we can go say git commit. And instead of pressing Enter right now right here, what I can do is use a shortcut and provide my commit message right there. Instead of I am adding or I created b. And that's my short commit message. And then I want to commit. So when you commit like this, it does not open the editor. It just takes the commit message right from the command itself. And off it goes. So you can see that now we have a new hash. This is 3a5520e. And it says I created b. One file changed, zero inserted, zero deleted. And that is what you see in this git repository right now. Let's say git status. We have on the branch master, nothing to commit. And working directory is clean. Which means we have actually created another point or reference. This reference is called 3a5520e. And this has a different hash. So this git hash is a different hash. Let us see that git hash. We can see both these hashes by saying git log. We can see that the log is at the very bottom, this guy created at this date and time. Hey, this is my first commit. I'm trying to commit a new file called a. And that commit hash is this b3bbaf. This b3bbaf that I highlighted is the same hash that you had here, b3baaf. That hash comes from here. And this hash, it's a short portion, first few characters of that hash, are referenced in the short reference here and here. It's the same thing like this long one. And that hexadecimal string that you see is a commit hash or a commit tag. Basically, every location, every state that you have. This is a state. Every state of the folder gets a commit hash like this. And we can go to, I created b in that location. We can go there. Or you can go back to where you are here. Or you can add more, like, for example, c. And then what I will do is create a file called c and git status. And I'll see that there is untracked file. I don't know what to do with it. So I want to track it. And so now I know that git status is that we have a new file. We don't know what to do with it. Do you want to commit it? So we can commit it. We can change to be committed, new file, c. We can commit this file, git commit. And a message saying, add c. Simple short message. So now I have another commit hash. C9. And by the way, I have created a commit hash out of it. And so we now have 5049CE9. That's the commit hash. So every tinker toy that you have here gets a commit hash like this. And it represents the state of the folder at that time. Let us see what it means again, git log. At the beginning, this hash. Then I create b. Then I add c. So the date and time in the author are all recorded in the log entry for git. And so you have this whole tree represented going upwards into the future from history, history at the bottom, future at the top, and current at the latest at the top. And that's what you see is this new tree getting formed. And you can traverse on the tree just like you want to. For example, I will now first of all list out what do I have in my folder. And I have a, b, and c. But imagine I want to go here in this point in time. So what do I do? I will just say git checkout v3baaf. And off we go. So what do we have now? Let us see. ls-la. We just have the state as it was to begin with. And I think this file may confuse a little bit. So I'm going to just erase it for now. I'm going to rm.dstore just to reduce confusion. Because that file actually is an artifact we don't want. We'll deal with how to deal with those things that show up and we don't want. How do we deal with that? Just a minute later. But I'm just removing it just to not confuse everybody. So we now have git log. And in the log, we only have one entry. This is my first commit. That doesn't mean that we don't have other items reserved. We can always go back to wherever we feel like. And suddenly I want to go to this location, say for example, I want to traverse from this location which I'm currently at. I want to change my state to this location. And so I can just quickly jump by checking out this tag. And that's what a git checkout is. So git checkout 5049CE9. And off we go. And so now let us see the list. We have A, B, and C. We see that the.git folder also exists. It doesn't go away. It just helps us manage our folder structure and various states of that folder in form of git control. So we have these three hashes. One, two, three. That basically keeps track of every change we ever did and added and committed in form of a git log. It keeps track of every single thing you do. So now if I want to make a further change and actually this time modify the file itself, so add C that I added the C file, I want to actually edit that file in Notepad or other Atom. And in Atom, you will see that this folder structure has A, B, and C files, three files. So what I want to be able to do is in this file C, I will write, this is a file where I will, where I want to store the third character in English alphabet. And that's what I wrote. And I save it. So now when I save this file, you see that Atom is smart. It understands that there is a change and it actually highlights the yellow color of the change. So you can see that this line C is added green colored. This green shows Atom is smart to understand these details. By the way, Git is also helping Atom in doing that. So if you say Git status, you will see that something was modified. C got modified. It is not added, it was modified. So we can see what was the change and we can identify by doing a git diff. What did we change? You see that the green line shows that this is the file where I want to store the third character in English alphabet. That's line got added and there is no other minus or red sign. This plus sign shows additions, no minus yet. So we will see those differences in git diff later. For now, we just have added, not deleted anything. So now I will go and correct a mistake in typing or rather first, let me add one more. So I want to git add and then git commit. And here, I am saying that some changes, some language added. And so that commit message inserted. We now have a new head, DCF15, whatever that number is. And so let's see git log. And we see that first commit created B, added C, language added, and that tree is growing now. The tree is going wild. And so we want to keep growing the tree until, and I'm just showing very trivial examples of how simple ABC that we are using to create. And you can actually add multiple files, multiple folders in one commit. You don't have to do line by line, item by item. You can just do bulk at a time and commit the whole thing and understand and manage the differences. So in our case, we have added some language for the file called C. And so if you now go to that state that we have, so let us open another terminal here. Let it make it big a little bit and put it side by side and go to that using git folder. And what I intend to do is I want to go back to this added C state. This commit hash. And so what I will do is currently I'll cat C and see we have something written in that file called cat C. We'll open atom editor here. We have this file containing something. And so this file contains that line and all that good stuff is in, it's there, it's visible to you. That's great. But what I want to do now is do a git checkout. And I want to go back to a little bit before, file 049. So let's say file 049. And so now I am at file 049 CE9, which is this tag. I'm back at added C, which means I should now open atom and find out what does my C contain? What do you think C will contain when I click it? What do you think C will have? If I click the letter C, what do you think you will see in atom? You will see nothing. Because in this state, we have added an empty file. If you go back to this hash, like git checkout, and now you will see the language. If you go back to this hash, git checkout, you will see that the file C contains nothing. Similarly, if you go back to this checkout, git checkout, you will see that the file C has disappeared. It never existed at that time in this checkout. If you go back to this checkout, you will find that our files B and C are disappeared, because we are on that initial position, that point in time. You can go back to here, if you like, in that topmost. So git checkout, and watch atom on the side so you will have some fun. You will see as soon as the checkout, atom brings it up and shows it. And so the folder automatically goes and disappears. The files will go and come back depending on what you're doing with git. Whatever you feel like you can do, as you can see various examples, I am playing around and you can see the changes happening live in your folder as shown by Atom Editor. And this not just happens at the file level, but also happens inside the file also. Not just the file names, but also inside the file. We'll see that how it actually works. So we'll edit that file again, this atom file we have. First of all, let me go back to the master, git checkout, master. And so we are now at DCF15A. Is that right? Yes. And so you are leaving one commit behind, not connected to any branches. So let's go to that commit, DCF15A. So we will go git checkout and enter. And now if you see the git status, you will see that it is at dfc15a4, which is that one. Which means we now have all these files and the file c contains the description we had in English. And a is blank, b is blank, c has this writer. Now, if you go back and carefully look at the folder now, it has this.git folder and abc3 files. If for some reason I manage to get rid of my git repository, everything about the state and everything about all that diagram and all the information about git control and the previous stages and all of that is lost because we don't have it in git anymore. There is no git repository here. Git status, this is not a git repository. I think my keyboard batteries are low. So that's what it's complaining about. So it's not a git repository because I just deleted the whole thing. So now we have the files, but it is not a git repository anymore because I deleted all the information that was stored in the.git folder, essentially got rid of git. So we still have the files, but all the detail about how the folder was constructed and what steps we did at what time, who did that, all of that information is all lost. And so it is important to not mess with this folder, but instead just operate on it using git command and operate and manage your folder using it. So that's the common usage. Now let us go into some examples with you will participate. So what I would like to do is, oh, it did not work for him. Wow. Sorry about that. Please join from the computer. He's not going to join for some reason. I don't know what's going on. So in terms of real exercise, what I'm going to do is open GitHub and go there to github.com, which I believe most of you have accounts already by now, I am assuming. So what I'm going to do is log in as myself and once I log in, I am connected to the CloudGMS account and here I will, first of all, visually create a new repository. So we will not use the command line tool for now, but just all of us, let us go to that GitHub and look at this link that I'm going to paste in Slack chat. I'm going to create a new repository and in that location, I'm going to say using git. It is a description. The description is we are learning to use git and I'm going to initialize that repository with the readme file. So it is not necessary, but you don't have to. Initialization with the readme file is not necessary. You don't have to have a readme. But it's good to have, so we'll keep it. And then we'll create a repository and we'll mark it public so everybody can access it and create. So now we have a repository created. This file, this repository is available for you to also operate upon. So you are going to access it in this location. It is a public repository and you can access it at this link. Now here, what I intend to do is make you contributors. So you can also add and modify and update. And you will begin with using this visually. And what I'm going to show you just using the browser, you don't need any terminal for this exercise, just using the browser. You can actually create, commit, add, push, pull. Most of these things you can just do visually because GitHub is now much nicer than what it used to be. And it has the capability to drive just by looking at what's going on. So you just have to understand that in this using git folder, I have only one file and that file is called readme. And so I'm going to make a change and edit that file right now. So I have an editor here. I will just open that file and then edit the file right in the browser and here say, we are learning to use git. And let us add a file to this repository. Let us each add a file to this repository by using these steps. Clone this repo. And the first step is to clone the repo. Second step, add a file. Third step, commit. And then fourth step is to send a pull request. That's the action plan. That's what we will do. And I'll describe what that will entail. I'll do a couple of things for you. And in here, the commit message, the commit message I'm adding is, I am updating readme with instructions. And now I'm going to commit that change. And here I committed it. Now you can see that we are learning to use git. And I have made this modification. And you can see the history. Initial commit was two minutes ago, just this much. And now we have a change. The change happens to be, the new change happens to be, if you look at history again, the latest file has these things added. And you can see the red line showing this line was deleted with a period. The period was not there, so I added a period. And then I added these additional lines. And that's what you see in the green color. These are the lines added. The red line was deleted. And that's the commit that I did. What I would like you to do is to actually pull. Sorry, actually fork this. I should update. I made a mistake. Not clone the repo, but fork the repo. So I should make that modification again. I made a mistake in writing this. It's not clone this repo, but actually you should fork this repo. So what does that mean? I will describe that. First of all, let me make that edit one more time. So instead of cloning this repo, I would like to say fork this repo. Add a file like I describe, like I will describe. And then you commit it back to your fork and send a pull request to Nilesh. That's the step we will do. And we will again commit these changes back. So you will see that the instructions are updated now. And the idea is first step, fork this. So what I would like to do is ask you to click this fork button and fork it. That link is available in Slack chat. Go there and fork it. You should log in first. And that will give you a quick understanding of... So go here and fork. So as soon as you fork, you should see something popping up in your account. Basically, this repository will become... You will have a copy of the whole repository in your account. What is going to happen by now? In my account, what I have done is in that repo, I began with nothing. I added a readme file. In that readme file, I made some instructions. So instructions added. And then I edited the instructions, edited instructions. So three steps that you already see are available in form of a git commit hash here, another git commit hash here, and an initial commit with readme created. So these three commit hashes in form of a git structure is what you currently see. And that's what you have in my account. When you fork it, you will see that you will create a replica of the exact same thing, the whole thing in your account. And that is what you're basically doing is making a fork. You're basically creating a replica of this and saying, you know what? Here, I have my own iteration of the same exact thing. And I can do whatever I want with this fork. This is a fork. This is the origin. This is the beginning where I began, but then you forked it. So literally, it is a fork like this. If more people fork it, you will have forks like this going. And that is what is going on, that you will fork the repository by clicking the fork button. I don't know if you have actually, oh, there are two forks. So we have two people forked it. And the members are Munir and Totapo. Okay, that must be Tosin, I guess. Yeah, that's me. My name was already taken. I see. I see. So, yeah, so Muhammad and Tosin have taken it. So what I would like you guys to do is you have the same git repository like I have. And what I would like you to do is modify it. And to be specific, I would like you. So we now, we have this, I created this branch, origin master branch. You have a Tosin fork and a Munir fork. And so we'll have more forks momentarily. And so what you have is the same git structure that I have in your case. What I would like Tosin to do is add a file called Tosin in to your own account. And create another commit hash here. So we have this one, two, and three already. So one, two, three commit hashes that I did already to begin with. And you have the same copy one, two, and three. And one, two, and three and more people will have the same thing. And what I would like Tosin to do is add a file called Tosin. And then commit that file into your repository. So this change I would like you to make. So this one, two, and three, these changes I made. I would like you to do this fourth change in which you will add a new file called Tosin. And here you have one, two, three Munir. I would like you to create a new file called Munir. And add and commit that file to create the fourth point. And that is going to be your commit. And similarly, other people, please add your own names. Let's see who else is already forked. So I think you're still working on it. So as the people will fork, you will have their own names that you would like to add. And then you commit. And so you will have a brand structure kind of sort of like this. So I began one, two, three. That's what I have. You have a fork of it. One, two, three. And then Tosin added. And that becomes point number four. And like that, one, two, three, Munir and point number four. What I would like to now do, once you have these changes incorporated and committed, basically you create a new file. How do you do that? So you go to the browser. In your commit, you will say, create new file. Click. That's how you create. You give it a name, Tosin. And then, hey, this is Tosin. And then you propose that new file. That's what you will do. Actually, you will see a commit message, not propose. So I'm messing around with Munir's fork and writing Tosin there. That's a mistake. So I should not do that. I should cancel. But when you see on your computer, you should not see, propose new file. But instead, you should see something like, commit new file. You could say, a new file, when you say, in your own fork, create new file. And here, I will call it Nilesh. And here, hey, this is Nilesh. And in there, I'm going to create a new commit message called create Nilesh. And add additional commit details if I want. And then, commit. That's what you should see, that a new file called Nilesh show up. And in addition to the readme file. That's what you should see in your own iterations, in your own forks. Now, we have four people forked it. And the members are, okay, Paul also did. So Paul, you will also do the same way, which is basically create a new file in there. And in that file, you will create a Paul file, just like I created in my account. And so, you cannot create directly into my account, because you are not me, and I am not you. And so, what you need to do is, when I go to, say, Mohammed's fork. For example, Munir's fork, right there. And so, here, what I need to do is, basically, if I want to make a change, I need to send a pull request to him. So, if I create a new file, and I type something here, say something, and here is something, then I have to propose that file to Munir. But this repository is actually mine as well. So, if I am on his repository, directly on Munir, if I try to create a new file in his repository, in Munir's, and I say create a new file, I can, but it will become a request. I cannot directly commit to his work. And I'll explain that. What does that mean? So, here, the authority to read and write is with me. Here, the authority to read and write is with Tosin. Read and write with Munir. And here, read and write authority is with Paul. And so, the scenario, essentially, is that you can read and write onto your own branch, your own fork. But if you ideally want to actually bring all these changes back to the master location, so that you can collaborate as a team, you need to send these things. These things that you send across are called pull requests. Because you cannot push yourself directly. You don't have the right permissions onto the origin. So, think of it as this team leader who creates and maintains the project. All the team members have their own copies, their own forks, and they can modify whatever they want inside their local fork. But as you create a new file and you want that file to be incorporated in the main tree, you will send a pull request like this. And that's what is going to happen when you modify your own fork. You should be able to send a pull request. And I cannot see what you see. So, what I would like to actually do is maybe request one of you to project the screen so that we can see and help you in sending a pull request over to me. And so, you will have my screen in which we will see what we are dealing with in this location. I have four commits. There is a pull request right there. So, we have Paul has sent a pull request and that's how he basically did. What he did is let us understand. Paul has changed one file. He said a new file, creating a new file now, and that file he has sent over as a request for me to pull. And he committed that on GitHub three minutes ago. And the request that he is sending is, hey, I have some inputs not so blank now. So, he further made further addition changes. And that file changes, you can see the file itself is this language inserted into that file. And so, basically, there are two commits that he is sending. This is one of those commits. So, I like this commit. I'll say thumbs up. And I like this commit as well. So, I'll say thumbs up. And since I like these commits and I see that it is good for me to merge into my repository, what I will do before I merge, before I merge the request, is I would like to actually go and examine what do we currently have. So, in our current folder, in our repository, what do we have? A file called readme and a file called nilesh. Good. But we don't have the file sent by Paul. This is Paul, by the way, umacscos. And so, lots of people are thumbing up. And Munir also thumbs up that same file. So, looks like the team seems to like this change that Paul is suggesting, which means that I want to incorporate that file into my main branch. And by the way, I noticed that the branch has no conflict with the base branch, which means I can comfortably incorporate the change into my main branch. And so, when I refresh this page, it should show me this new file that Paul has sent. So, I'm going to merge that pull request by clicking here and actually writing a little thank you note to Paul, saying thank you very much, Paul. Thanks very much. And then I close and comment. And before that, I have to confirm this merge. So, I confirm and then thank you very much message I send and I comment. And so, I formally thank my team member. And in that, this merge has happened. So, you can see this picture shows that the merge has actually happened. It says nilesh merge discovered into this master branch just now, which means we can now go back to our master location, refresh the page, and see this new file, this new file, a new file contains this new line. And that's the change we are able to incorporate. And so, while doing this, we now have some more history to our tree. So, let us go see our master and we can see our six commits. We have a bunch of commits here. I began, I added, I modified, then I created a file called nilesh. Then we have Paul added a new file, then I took that file and incorporated and merged the pull request number one from Paul into the master. And so, we have that the tree is building up. As you can see, the commit tree is building up. So, we are able to cooperate, collaborate on the same folder structure while using it. But we have three items that this item was contribution from Paul. And that's what we are looking at. Let's see if there are more pull requests quite yet. So, no, there are not yet. There are not yet any pull requests. One of them is closed. So, this request was closed because we actually incorporated the change. And that's what we are looking at. And the fine change you can see and identify who modified what, when, and all that good stuff. But I would like everybody to make a change, a pull request, for which I need to see some of your screens so that I can help you in actually making sure that the pull request succeeds. So, why don't you let me stop sharing and share your screens. I can see what you're dealing with in terms of this pull request that you want to send over so that we can operate on the same thing together. I would like to help you in sending a pull request that you understand. Once you understand the concept, doing it is very, very simple. So, anybody wants to project? I'll project. I thought I created a pull request, but I guess it's not... Okay. I see your screen. And I'd like to point out to you is that you are currently looking at a folder called be a cloud genius kit. And so, this is my repository, right? So, this is mine. So, we have to actually fork, which you have. And so, you have forked it. And so, that fork is available in your account. So, let us go to your fork. And so, this is your fork right there. We see the graph, the members, and we see those in there. And so, this is now total using git. And so, that is the current folder that we want to actually make a change in. Right. In that folder, we will go look at the code in that location. And here, you have added Tosin. So, that's the change you have incorporated. Now, you have to compare this with the origin location and create a pull request. So, you compare and see that create Tosin. And you're basically creating a new pull request right now. And that is what will happen when you send a create a pull request message. It will send that request over to me. And so, it says Totapo wants to merge into the master. So, this branch has no conflict. Basically, it means that this file that you have incorporated as a change in your repository here will automatically get sent over to me through a pull request that you just created. Which means I will now ask you to stop sharing your screen and I will start sharing my screen so I can show you. So, I'm taking my control over, sharing my screen. And in my screen, you see that I now have that same location, the repository that we have. And here, we have another pull request, actually two pull requests coming from Tosin created a pull request called number three for me. And she has proposed a file change. This is a file called Tosin contains, this is a test. And that change, I think I like it. So, I am going to look at the pull request and say that, you know what, this pull request, I will like to merge it. So, I want to maybe give her a good thumbs up reaction, merge the pull request, confirm the merge. And then thank her and then comment. So, she knows that I have actually incorporated. You can see that Nilesh merged this commit into the master branch for Cloud Genius. And let's go back to the origin location and see what we have. We have Tosin and a new file and Nilesh. And so, these team members, all of us are actually making contribution to the folder. And we exactly know who's doing what is contribution, what their contributions are. And so, we can see that, you know, here we are incorporated this from Tosin, this from Paul. And this Paul created that file. I have created this file. Tosin created this file. And so, these changes are according to the time sequence when they are happening, when they are getting into the branch structure. And we can just go to any point in time, any commit hash. And as you can see, these commit hashes are available to us. You can just jump to our wheel if I want to go to that point and just click there and we jump. And so, we are just able to see anything, any point in time snapshot of the state of the folder we are working with. So, that is what we are dealing with right now. We have another pull request, by the way, coming up, which is again by Tosin. And so, here it has a conflict that must be resolved. So, use the command line to resolve conflict before continuing. This is a test from Mohammed. So, Mohammed commented. And I think this is a test. The file, the same file got edited by two people apparently. So, that is the conflict. And this is a test from Mohammed. Created update Tosin. So, the conflict we can resolve. The conflict happens when you have the same file being edited by multiple people or have the same file name. So, a conflict basically comes from the fact that you are colliding on the namespace. So, you have a file, say for example, hello.txt in the folder at the top level. And so, at the top level, if I have a file hello.txt already and you also create another file called hello.txt, then we are basically colliding. And so, this collision can be resolved through only one way and that is negotiation or discussion. So, negotiation or discussion needs to happen between these two people. And the best way to resolve that collision is to talk. Hey, who's right? This is right or that is right? So, you just figure it out what is correct and then once you have a common understanding, you just delete this one and take that one or maybe delete this one or take that one. But that has to happen because the same file name cannot coexist. It is a collision and you want to avoid and that is exactly what is a Morse conflict. That's what you're looking at in this example, which is what has happened. I think Tosir and Muhammad used the same name apparently, which is what has happened in your side in this pull request, which has resulted in a conflict. So, we can resolve the conflict or we can just ignore the conflict and move ahead. We can just say that, you know what, we will reject this as a proposed change. We will say, you know, this change, I am not accepting. This change will say these two commits, I'm not going to accept. We will say close the pull request and sorry. And it says sorry, cannot accept this change and comment. And that's how you can address that particular pull request, which is now closed. So, we have three pull requests. One of them we rejected, two we took and the resulting output is here. And that's what you're looking at. And what we now need to do is get the whole thing that we have in that particular folder down and we want to bring it down to our local machine. So, which is what I intend to do is I'll open terminal and then clone it. So, when I'm cloning it locally into my computer, I need to make sure that I do not collide with the namespace. So, I think I have a folder called using git already. And the folder name that I'm about to clone is also the same name. See, using it and this folder already exists. So, if I just clone it, say git and clone, let me make it a little big. So, git and clone and do this way, it will collide. So, there's already some content called using git in the current folder. It exists there. So, if I do it like that, it is going to cause problems. So, the good way to do that is either delete that folder already to begin with and then run this clone exercise or have this go somewhere else, like go somewhere else. You can send it to another folder and that is okay. And so, I will say yes to it and it will clone the whole thing locally and I'll go to the somewhere else folder. And here I can open Atom Editor and you will see in the Atom Editor, what do you see? Let's go find out. So, Atom is opening up and you will see that the Atom Editor has the new file from Paul, this file called delish, this file which is instructions and this file created by Tosin. And you will see the same thing here in git log. All those steps that we have done up until now are showing up. These changes with commit hashes showing and who's doing at what time and your email address, your email address here and things like that, they will just show up automatically depending on what the person who was making that commit, at what time, doing what action, and the commit hashes, they will all become visible here. And you can see that in your command line. And by the way, for git, there are various decent graphical user interface software available. And one of them is called GitHub for desktop. That is available and you can download it here and it is free. And you can use that in Windows, Mac, Linux, not Linux, sorry, Windows and Mac only. There is another one which is also nice. It is called source3app.com. Source3app is available for Windows and Mac and it is a git and Mercurial client. Mercurial is HG, like I mentioned before. And this I actually like. The reason I like it is also free, by the way. There is a free license available. You can get a license from Atlassian company, which is an Australian company, and they give it to you for free. So the idea behind this actually resembles the discussion that this four-year-old had, I mean, the git for four-year-old that video had about Tinker Toys. You can see that these Tinker Toys actually visually represent like this, the dots that you see here. These dots that you are looking at. And that is what is visual representation of who is the author, what the description was. And you can visually play around using this source3app. So I am going to take both these links for you in Slack chat. Paste them. And that source3app thing. Also, I will get a link for you. Both of them are free. You should use it, whichever you like. It is a visual tool, but not every place you will have the capability to open your thing, open your content in a, let's see if I have source3. Yeah, I do. So I am going to open this particular folder that I have cloned locally from GitHub. This folder, using it, that I have locally cloned in my somewhere else folder. And so what I will do is in that folder somewhere else, where the typo there apparently. No, there is no typo. So in that name somewhere else, I will open the source3 editor. And what do you see now? Let us go carefully see that. So this is the somewhere else folder, as you can see. And it shows you the Tinker Toy description that I was talking about before. Watch the, watch the portion which I am going to highlight for you a little bit. So watch this area. This is where I begin with the initial commit. And in the initial commit at the bottom, you can also see visually that the readme file is getting created with only this content in blue color. As I go ahead and update the readme with a little bit more detail, I remove the red line and I add the green items. I get another commit hash. The hash is actually hiding here, so I'll bring it over here. And the author name is hiding here, so I can maybe put it right there. And so now I can see that the author's names, descriptions, and the graph showing me how these transitions are happening. So you can see that at this time, I make further changes to the writeup. Instead of clone, I say that, you know what, let us fork. File, like I will describe. Commit. Commit back to your fork. And send a pull request to Nilesh. So those lines are changed. And that change is showing in red and green, as you can see, in that commit hash number 58 Echo Fox track 26f. And that's what you see in this example. As you go along, you will find that this person, this yellow colored person, which is represented by yellow color, is actually Paul. And what Paul is doing is he creates a new file and calls it a new file. And that file gets created at this timestamp, which at a later stage, I merge that pull request from Paul into the master. So you see the yellow thing going here. You can see that it is actually incorporating that. Hold on. I hope I did not disturb the audio. I think I made a wrong key press. I hope I did not disturb the audio. I hope you can still hear me, right? Yeah, we hear you. Okay, good. So this Paul's change that you have here in the yellow color gets incorporated into this commit hash with seven Bravo, Echo Bravo, like that. And then Tosin comes along and says, you know what, here is my change that we have in this color. And she creates this file. This is a test message. And that gets added on to the merge, which I have merged here. And you can see that these tags for master, origin master, origin head, is something that I would like to now describe a little bit to you as to what is going on. And now we have played with Git using terminal. I would like to play with Git a little bit on the GUI also, just to give you a flavor of what exactly Git can do for us. And so as you can see in the tree that we have constructed collectively together, what I want to be able to do is go to my beginning point like this here and actually check out. Excuse me. I want to check that Delta eight Bravo seven item that commit hash. I want to check it out. So I will just double click on it, like click, click. And it says, are you sure you want to check out that thing? And I'll say, yeah. And so what do you see in the atom editor? Just the initial. Now I will go to the next step. I want to now check out. And by the way, you will also notice one thing, which is see the description. My head pointer is down here at the very bottom at Delta eight Bravo seven. Head pointer is now at the very bottom. If I go back to the nine nine alpha one and double click on that, you will see that the head pointer will move all the way to the top. So I'll just double click on this commit at the very top nine nine alpha one double click. And you see that the head pointer goes all the way here. And you also see that the atom editor brings up all the new content as represented by this state. I will now traverse to another point. Let's say this one. And so that is where I want to go, which means I will double click, click, click this one one two six zero. And it says, are you sure you want to go to one six zero? It will be a detached head. This head will go back in a random location like, like you choose. Do you really want to go there? I'll say yes. And I can go there. The head comes down from here all the way to here. Head is usually at the top, but I can take my head wherever I feel like. And you see that the file Tosin is missing because I am on that particular commit, which is actually on a different branch, not on my main tree at all. So even Nilesh file is missing. Tosin is missing. A new file from Paul is available. That's what you see visually on the left side. That's what you see actually in the atom editor. And I can take this head pointer wherever I feel like. So this head is actually conceptually the idea of a turn table where you can play music and you have the head or the stylus where the table turns and you play a music and this thing you can just put wherever you feel like this black item. You just lift it and put it anywhere or across the radius. So the head can belong to any point in this location. You can just go to the next song or previous song. You can just take this head of the turn table and move it from here to another location, like here, for example, and the head goes there. And you can move the head wherever you feel like. And that's the kind of idea behind this head. And so I want to take my head back to 99 alpha one, click, click. And this time make a change to the repository using terminal. So I have the my keyboard seems to be dying. My terminal is available. I'll create a new file here, touch and call it hello dot txt. And you can see that the file gets created in atom. This file showed up in that file. I'll say this is hello file and I'll save it. Now I have that file as a item to be committed. So I check that good status and I see that this hello dot txt is untracked. Now let us look at it visually. Visually you see that there are uncommitted changes. The uncommitted changes are there's this hello dot txt file, which is actually has this content. So I can visually click this button and effectively I ran the add command to get add. I just ran that by a click of a mouse. I can remove the ad by clicking it again. So I'm now back at the state it was. I can go back and click it again visually to add it. Now I can check my git status and you can see that there is a new file. I can go back here and remove the addition and go back here and check git status. And I can see that there is an untracked file. Go back again, add and check the status. Oh, there is a new file to be added or new file to be committed. That's how you can just see that you can do the same thing visually. So that was the git add command with a mouse button. Now once you add it, you still have uncommitted changes. So then you want to actually commit them. So this new file that we have hello dot txt, we want to commit that change. For which there is a specific commit button. Commit button, it should be right there at the very top left. Commit. So here I want to commit this change called hello dot txt. This is a hello file and here I want to say that I am adding hello dot txt. And so that is a commit that I just made. So I have it now. I go back to my git status and I can see that git status shows that the branch is mastered. My branch is ahead of the origin master by one commit. What does that mean? So we have this one ahead and this is origin master. This is my local master and this is the origin head. This is my current head, my local head. And let us understand what this means. Git is fairly elaborate. I can talk about git for eight hours nonstop, but I don't think you want to stay that long. So I understand you. I think you are already like one hour, 30 minutes into it. So I'll give it piece by piece. Maybe we'll do more discussions on git if there is more interest. However, what we are really talking about is this copy that I have in git hub, which is where I began. So that is the origin. And then I cloned it locally. And that is my clone. This is my local. In my local clone, I have added this hello. And so this is where my head is pointing right now. This head kind of matches this head git hub. The git hub is all the way up to here. All these changes we have with Paul adding his commits and then Tosin adding her commits. And we are all incorporating those in our. That's the git structure that we currently see in git hub in the origin. We have a clone of the whole thing here. But then on top, we are adding another thing. This thing is called hello. That's where we are now after a commit. So after this commit, my head goes to this location. That's my head pointer. So this means my origin head is actually pointing here. And this was the prior position of the head, prior head was here. And now, since I have added hello, my head pointer goes to this location. So what does that language mean here? Is that your branch, meaning your local branch, is ahead of the origin master by one commit. Visually, it means this thing is behind and this is ahead. So this hello is a new thing that this origin does not have. That's what it means, your local is ahead of origin slash head. Local head is ahead. One step, one commit ahead. One commit ahead of the origin head. So how do we bring them into the same page? We can by doing what is known as a push. So let's go to GitHub and let's go examine here. Do we have that file called hello? No. No, we don't. How do we send that hello file here into GitHub? Is what this action called push. And you can see visually it says one push. And you can push it to the origin master. The remote branch is also called master. The local branch is also called master and I can just click the OK button and it will send that change to GitHub just like that. Or I can do git push. Both of them are equivalent. So I can do a git push on the terminal and that works. It will send that change to GitHub. And now this flag actually goes away eventually. When I refresh, you will see that this flag disappears because the push has already been taken care of. As you can see, this GitHub location will actually, when I refresh, it will show you hello.txt, which is a line that I added on my computer locally. I am adding hello.txt as the message. And that is what we just did with a push. We did a bunch of things today. What we did is we began with understanding what git is. We did an exercise with creating a basic folder structure. We traversed across the tree, going up and down. Then we played around with our own GitHub installation, initialization of a repository. So we began with my own repository that you forked. And all of you forked it and you created your own changes and then you send those forks, send those pull requests to me. I incorporated them and then I took that change over. And then what I did was what we're doing here is making a change and then pull request. That's what you did, change plus pull request. What I did after that, all of that, is I cloned the whole thing locally and then made a change myself. I did an add commit myself. And then I did push. I did a push. This push actually sends the changes back to where it came from. It came from this clone location. It goes back to where it came from. It knows where to go, where to send. You can see that detail by examining in visually the settings for the repository in the remote section. You can see that the origin happens to be GitHub B.A. Cloud genius using it. So it knows where it comes from and it just sends it automatically where it came from. Similarly, you can see that Git remote here in terminal. Same way, Git remotes dash V. And you can see the Git remotes were disconnected too. That's why just saying Git push, it knows where to go and it automatically goes there. In Heroku exercise, you will remember you have done it before. Git remote will show you instead of GitHub remote, it was a Heroku remote. So we had a slightly different way of representing. We were using the command Git push Heroku master as opposed to in our example, it was just Git push or you can say Git push GitHub or origin master. And that command will push nothing because everything is already up to date. And that was the difference between Heroku and origin. In our example, the origin is this location that we used, which is the GitHub location. And that was actually a very short quick discussion on Git. I would like to ask if there are any questions for this or do you have appetite to go deeper or I'll let you tell me what you want. We can go on. Git is such a complex subject. I'm barely scratching the surface right now. So I like to hear your thoughts. Do you want more of this? In general, not just Git, but in general about the way we are approaching the program. What do you think you like? What do you think you don't like? And I would like to hear that. So I would like to also ask you this question. How do you want me to change? And I keep asking that question, but nobody actually tells me that. What do you want me to change? So I haven't actually heard from any one of you to change something, which means everything is just perfectly fine, which I find it hard to believe. But I'm happy if you say that so, but I actually don't buy it. So tell me, what do you want to change, improve? Because I really, really want the program to be improved. And that is my goal. So we are doing this program right now and I want you to do the exercise, which I hope you will do by today or tomorrow. And that exercise was, what was that exercise? MySQL. Where is that? Here. Set up a node that has a MySQL server ready with root password. That exercise, I would like you to really, really do it and show it to me that you did in Slack chat or one-on-one. And so we are meeting again tomorrow. Tomorrow is Wednesday at five o'clock. We will meet again. Yes. Questions on this? One second. Hey, sorry about that. No worries. I closed out the laptop because I was trying to copy what you were doing. That video from today, the one that we just worked on, will you be posting it sometime today? Because I want to re-watch it again and write down notes and then try it again. I will actually stop recording and then make it available through the same way like I do it usually, the same way, same location. It will just pop up. I'm going to re-watch it again. Let me actually stop recording for this one. And we get a file for you. Fine, I'll drop in the same folder as you know already.