Archive for the 'Software' category

Anatomy of a git diff

published on December 20, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

I’m looking at git diffs every day, all day. Diffs hold a lot of information that can be valuable, and I think it’s a good thing to know how to fully read a git diff.

A simple diff looks something like this:

diff --git a/example.php b/example.php
index a5174a9..11aeb84 100644
--- a/example.php
+++ b/example.php
@@ -11,7 +11,10 @@ class Greeter
         $this->name = $name;
     }
 
-    public function greet()
+    /**
+     * Return the greeting message.
+     */
+    public function greet() : string
     {
         return sprintf("Hello %s" . PHP_EOL, $this->name);
     }

This simple example holds most of the information that is needed from a diff.

The first line tells that the diff is in the git format and the filename(s) before and after the changes.

The second line tells about the type of file and its permissions (100644) and the two hashes are just that - shortened hashes of the pre- and post-images. AFAIK, this line is used when doing 3-way merges.

The lines 3 and 4 again deal with the name of the file(s). If it’s a new file, the source - --- - is /dev/null, and if an existing file was deleted, the target - +++ - will be /dev/null.

I’ll skip line 5 for a moment and come back to it later.

The next part, the actuall diff, shows what lines in the current hunk were added and what lines were removed:

         $this->name = $name;
     }
 
-    public function greet()
+    /**
+     * Return the greeting message.
+     */
+    public function greet() : string
     {
         return sprintf("Hello %s" . PHP_EOL, $this->name);
     }

Lines that start with a + sign were added, and lines with a - sign were removed. Lines with no + or - are here just to give us some context of the code. Looking at this diff we see that one line was removed and 4 lines were added.

Now back to line 5 as this is probably the hardest part to understand:

@@ -11,7 +11,10 @@ class Greeter

These numbers always seemed random to me.

This line is, I belive, called “unified diff hunk identifier”, and the format of this line is:

@@ from-file-range to-file-range @@ [header]

which to be honest, isn’t that helpful. The @ signs are just delimiters.

The first pair of numbers, -11,7, means that the current hunk in the source file starts at line 11 and has a total of 7 lines.

The starting line can be confirmed in any editor: $this->name = $name; really is the 11th line in the edited file. That’s easy.

The number 7 means that there are 7 lines in total that have a - sign or no sign at all (contextual lines). If we count the number of contextual lines and lines with a -, skipping the lines with the + at the beginning, we see the total is 7.

The second pair of numbers, +11,10 means that the current hunk in the target file starts at line 11 and has a total of 10 lines.

The number 10 means that there are 10 lines in total that have a + sign or no sign at all (contextual lines). If we count the number of contextual lines and lines with a +, skipping the lines with the - at the beginning, we see the total is 10.

Finally, class Greeter, the [header] part of this line, tells us were did the change happen. This may, or may not, be present.

This example is a simple one, but I think it covers most of the use cases of a git diff output, and it helps us understand the unified diff hunk identifier line (the line with @@s), which is useful to know, especially when editing git hunks manually.

Happy hackin’!

Tags: git, diff, hunk.
Categories: Development, Software.

Editing Vim macros

published on December 15, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Vim macros are a powerful thing — they let us record keystrokes and play them back later. These macros are recorded to named registers.

One thing I realised about them, is that they can be edited after they have been recorded. This is possible because macros “lives” in the register.

Say, for example, you record a macro of 20+ keystrokes, play it back, only to realize that there’s a single error in the steps. Re-recording the entire macro can be difficult. Instead, paste the contents of that register somewhere, edit it, and then yank it back to that same register.

For a simple example, let’s assume we want to add * around words. We record it to the register a by typing qa (the ^[ is the literal escape character):

bi&^[ea&^[

Play it back with @a and — oh no! that’s not a *, that’s a &!

Vim macro editing to the rescue:

:new # to open a new split
"ap # take the register named "a" and paste from it
:%s/&/*/g # replace all & with *
^v$"ay # jump to start of line, visual mode, jump to end of line, take the named register "a" and yank to it

If we now play back the macro again with @a, we see the *s wrapping the word on which the cursor was, just what we wanted.

Happy hackin’!

Tags: vim, macro, registers.
Categories: Development, Software.

Renewing Let's Encrypt certificates

published on December 13, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

Back in July I wrote how to set up SSL certificates with Let’s Encrypt. One of my certificates was due to a renewal, and anticipating some work to renew it, I decided to blog how to renew a Let’s Encrypt certificate.

It was quite anticlimactic:

sudo certbot renew

That’s it. All that was required to renew a certificate. certbot even figures out which of the certificates is due to a renewal and renews only those.

Guess I can go back and do other things now.

Happy hackin’!

Verbose commiting

published on December 12, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

One thing I recently learned about git, is the -v or --verbose flag for the git commit command. It shows the diff of what is being commited in $EDITOR below the commit message template. Taken directly from man git commit:

Show unified diff between the HEAD commit and what would be committed at the bottom of the commit message template to help the user describe the commit by reminding what changes the commit has. Note that this diff output doesn’t have its lines prefixed with #. This diff will not be a part of the commit message.

I keep double checking the code that I commit, so prior to discovering this flag, I was constantly switching between writing the commit message and seeing what’s in the diff. This now gives me the diff inside vim, as that is my specified $EDITOR. I can navigate the diff using vim motions, use search, etc, which greatly improves my workflow.

Happy hackin’!

Tags: git, message, verbose, diff.
Categories: Software, Development.

Configure Fedora's firewall for Vagrant

published on December 09, 2016.
Heads-up! You're reading an old post and the information in it is quite probably outdated.

This one’s been in my drafts for a long time, might as well publish it.

FirewallD, Fedora’s firewall, has a set of zones, which basically enables to configure trusted network connections inside these zones. You can read more about FirewallD on it’s wiki page.

Whenever I bring up a Vagrant box for the first time, Fedora’s firewall blocks the NFS shares, because the new Vagrant network interface does not belong to any zone. The usual symptom of this is that Vagrant gets stuck on the mounting NFS shares step.

I have a zone called FedoraWorkstation that I use for all the Vagrant boxes I have on my laptop. This zone has a list of services that are allowed:

robert@odin ~$ sudo firewall-cmd --zone FedoraWorkstation --list-services
dhcpv6-client rpc-bind nfs mountd ssh samba-client

You can use any other zone you like, but you need to have the rpc-bind, nfs and mountd services allowed for that zone.

After bringing up the Vagrant box, we need to figure out what’s the name of the new Vagrant interface and add it to the firewall zone. Vagrant interfaces follow the naming schema of vboxnetX where X is a number:

robert@odin ~$ ip link show | grep "state UP" | grep "vbox"
7: vboxnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

From this we can see that the name of the interface is vboxnet3.

Let’s add it to the FedoraWorkstation zone and reload:

robert@odin ~$ sudo firewall-cmd --zone FedoraWorkstation --add-interface vboxnet3 --permanent
success
robert@odin ~$ sudo firewall-cmd --reload
success

Finally let’s make sure that the interface was indeed added:

robert@odin ~$ sudo firewall-cmd --zone FedoraWorkstation --list-interfaces
vboxnet3 vboxnet2 vboxnet0

And that’s it. Happy hackin’!

Robert Basic

Robert Basic

Software engineer, consultant, open source contributor.

Let's work together!

If you require outsourcing or consulting help on your projects, I'm available!

Robert Basic © 2008 — 2019
Get the feed