How to make a patch using git and apply it! C binary file.

As I was walking home from work today I got to thinking about patch files for some reason. Don't ask me, I just did. So I'm walking along, and thinking about how git has patch files as pretty simple things of add this in, take this out. Do that a bunch of times and poof. And I know what it looks like for source code. But then I also entertained the thought about executable files.

So without further a due:

First let's make a directory and hop into it.

Next, let's make our C file

Now compile the program...

Now comes the fun part. Make a new repository and commit it

Now let's make a change to the program

Now recompile the program and check out the status of our repository

We can see that we've modified everything (because we have) and that git is keeping track of our binary for us. So now how do we make a patch? Well, the easiest way to do it is to put these changes on another branch. This will let use some really easy to follow commands. So let's do that.

Next, I'll clear my console with clear and then create the patch. Because I'm alternating between a fullscreen guake terminal, and this blog post I get some weird spacing and the actual patch command to make a bazboz patch file from our current branch is about halfway down the screen.

Now, something you might notice is that since I've been using git add . I've not only added the binary file to the patch, but also the changes to the source code. If I was maintaining some type of non-open source project, or it was a configuration file that wasn't ignored for whatever reason, I would have only added the binary file to the patch. Not a big deal, but just something to take note of. To actually apply the patch file we've made, lets go ahead and switch to master

you might notice I'm already on master, that's just because I switched over in a separate terminal window and was testing the commands I was doing first, that way this little tutorial stays clean.  Once I've switched to the master branch I check to see if the patch is going to fail. Since no warnings or errors pop up from the check option from apply. We can go ahead now.

We could have applied the patch with git apply but if we use git am we sign off on the patch so that everyone who helps us maintain our code can point their fingers at us when something goes horribly wrong and our code is at fault. 

And that's all there is to it! Note that this is a pretty minimal example, and to be honest a patch really isn't necessary at all. If I were just grabbing a commit from another branch I would use git cherry-pick and select the hash of the commit I wanted to grab. But, if you were working on a project like, Drupal or some other large open source and you contributed to core modules and such, they'd probably want to take a patch to make it easy on them to integrate your changes. 

I didn't go into too much detail about anything I was doing I don't think, and if you want a more detailed explanation with a bit more time spent, I recommend This tutorial by Ariejan de Vroom

If you were emailed this patch file, you'd cd to your repository, checkout to your master branch (or whatever branch you want to apply the patch to) and then run the git am commands after dropping the patch file into the directory. Easy!

Easy Problem of Satisfiability

Problem:
  Given an expression consisting of AND,OR, and NOT gates, determine whether or not the output of the circuit can be made high. That is, the circuit has I inputs, N gates, and 1 final output.

Solution:
  I have one. This problem was described to me as the natural NP problem. Yet, it is extremely easy to solve in linear time at worst. Which confuses me. An NP problem should take sub-exponential or exponential or worse time to complete. Yet the algorithm I have come up with (I swear it's not in the margin of my notebook, actually takes up just a page) finds not only if the circuit is satisfiable but also implicitly gives back the neccesary input to cause the circuit to output low. Another caveat of my algorithm is that it can be used to find a way to cause a circuit to return low as well. It is very general, and the algorithm itself takes up only 150 lines of code or so. It's a beautiful recursive descent.

I'm meeting with my professor in a half hour to go over it with him. And after this, I will know if I have found a solution to the NP problem of Circuit satisfiability or if I missed the problem definition in some way and merely solved a problem similar, yet easier.

If all goes well, I'll post my algorithm later on today.