 So today I'll be talking on a topic of the day who requested. So I need to tell you that I'm currently an U.S. student interning at KIPAP. So before I jump to the main topic, I would like to give a short overview of the normal gift workflow. So what we normally do is we'll create a branch and after we add all the comments, then we'll submit a pull request. So we'll submit a pull request and somebody will review your code and they'll actually merge it and deploy it to life. So this is a typical workflow but under a specific scenario such as when we have no access to the server that you're currently working with or maybe your gift server is behind a firewall and without a VPN you couldn't access it. So we can do it with this special command and we can generate patches using this command called gift format patch. So as anybody use this command before, as I figured because this command is pretty... it don't need this under a normal scenario because it's actually a bad workflow if you think about it because what this command does is actually it will create a patch and you are supposed to email it to the person, the maintainer of the repo and he'll apply the patches on top of it. And this is under normal circumstances, it's actually not recommended but sometimes it may come handy if you know it. So now I'm going to give you a short demo on how to use this command. So in my demo folder, I actually have two repo. So I have two repo in my folder. So one is mine and the other one is John repo. So I'll start off in my repo. So as you can see I have a basic structure of a gift folder and I have two branches. One is a master, one is the new feature branch that I have extra comments on it. So let's go to this. So as you can see, my comments on this feature branch is actually much ahead of my master branch and now I'll show you how to create a patch on this. So the basic command is a gift format patch. So master is actually referring to the master branch so you'll compare the extra comments that you have on this branch against your master branch and by calling this sddout command you can actually redirect them to a new file that you want it to be. So I'll call it a newfeature.patch. Without the sddout and the redirection behind you actually generate numerous patches. So for example I have two comments ahead so I'll generate two files and to apply it is actually much more troublesome and to email it to. So by doing this you can combine you can squash two comments into one patch file. So as you can see, this is actually a new file called newfeature.patch. So if you take a closer look of the patch file it's actually just a gif that you normally see in your normal gif workflow for an entire gif. So it's actually just put into a text file. So what you can do with this this new patch file is you can just email it or copy it or use the git send email command which I will not cover in this thing. So what I'll do now is I'll just move it to our repo so you can see the patch file actually end up in this repo. So yeah. Then what you can do is before you apply the changes what you should normally do is you should create a new branch and do it like a normal workflow. You shouldn't apply these patches directly on your master branch. So what I'll do now is create a new branch called so what I'll do is I'll just apply it. So this git email will actually take in this newfeature.patch and apply it on top of my current common issue. So as you can see, now the two changes that I made change the color of haters and add new section haters and just apply it on top of it. Do note that by using this method the chart of the common issue is actually different from what you do on a normal workflow. So this chart is actually different from the chart of the original repo. So that's another reason why we have to we have to create another branch and merge it in so that there'll be a consistent seed so I think that's all from me. Any question? What do I have using like leaving patch and then putting everything? First, is that for that controller? Yeah, yeah. It just it just everyone has the same person in mind and I was about to ask Yeah, I'm just asking you. Is that that's it? That's all Yeah Any other questions? No, so this still means as in I mean this changes original repo and after I email so it's just it's essentially a github github actually reflects so you'll use the same order Yes It's just an accent as well No, as I said it's a github Yeah This is a bit of a second question But given this workflow what happens if there is a conflict when you apply the patch conflict On the other side as applied on the patch how do I tell the guy who sent me the pattern to do the conflict so when there's a conflict you actually something like something like rebase they'll ask you whether you want to continue or fix it or you want to abort so it's like similar control Any more questions? How is this different from if the guy just check out the branch from the original branch Sorry, what do you mean? So like as you know the other rappel they are the same they are from the same are they of the same? Okay, so before I make any changes both of the rappels are actually the same tracking the remote rappel so after I made some changes on my own rappel instead of submitting a pull request I'll send the patches file and I'll send this patches file to another collaborator and they'll use this command to apply as I see it's not a recommended way of doing it but under some circumstances you actually need it and yeah Just one question Sorry, what's your question? So at the end just a short question So at the end Yeah So on GitHub you actually show not sure if you see this committed by this person but it's authored by someone So you can see the same thing So So this workflow is more for when I don't have right access to the other rappel, right? Yeah, that's one of possible scenarios Yeah, but it's quite rare that this will be used I think it's still used by the Linux gun Okay Shouldn't you tell the guy send the patch that if he if he pushes those changes to the repo after he has access again that he's going to be expelled from the touch he has to do something about it, right? He cannot push it when you give it to the owner of the repo and he merges it in and he pushes it that would be a bad conflict for everyone, right? The moment that you pull Bang Yeah But there is it's essentially the same So to be John actually applies his patches on this branch you can submit a true request but this is useful when you work for a company like base data, for example when you have a firewall and you're on location and someone needs to pass on you so you just generate your commits and then format then send it to someone inside the company so you can submit a request on your own But do you keep it? No, you shouldn't So you should have RDSM Yeah One last question Just how they say for one branch we have 100 commits and then is there any way that we can after you punch in you find out that's not what you need or some errors then you undo that own batch So I think you have to do the revert like normal normal workflows revert the changes and you can't selectively apply unless you break it into smaller chunks as in what I said just now instead of you use an STD out you just use git patch command to master and without the parameters you just generate multiple patch files so you can patch whichever you want and you selectively patch it yeah so the thank you thank you