Applications


About restoring a deleted Git branch

Recently, a branch was deleted from the server without it being merged.
Luckily for us, we had a local copy.

We used used the command git reflog to get access to the reference logs of the branch.
The command returned results similar to the below:

271f0084 HEAD@{0}: pull: Merge made by the 'recursive' strategy.
 0e71c0b HEAD@{1}: commit: Minor change: Cracked NSA systems
 c81624b HEAD@{2}: pull: Fast-forward
 ef1f281 HEAD@{3}: commit (amend): Deployed satelite
 1ed1a5a HEAD@{4}: commit (amend): Deployed satelite
 a8682cb HEAD@{5}: commit (amend): Deployed satelite
 e4560c8 HEAD@{6}: commit (amend): Deployed satelite
 1679a90 HEAD@{7}: commit (amend): Deployed satelite
 d27d2c9 HEAD@{8}: commit: Deployed satelite
 aaf8261 HEAD@{9}: checkout: moving from master to crack-nsa-systems
 2500e11 HEAD@{10}: clone: from ssh://[email protected]:7999/secret/bananas.git

From this information we got the hash value in front of the commit which we wanted to use to restore, which was 271f0084.

Then, we checked out that version using

git checkout 271f0084;

When we tried to push the branch back to the server the Git pre commit hooks blocked the operation.
Based on the rsa key used, we could only submit changes that were committed by the owner of that key.
The option to disable temporarily the pre commit hooks was unfortunately out of the question.
So we had to replace all author names and emails with the name of the one holding the key.

To do so we used the following command before pushing to the server once more:

git filter-branch --commit-filter '
   if [ "$GIT_COMMITTER_NAME" = "Doe, John" ];
   then
     GIT_COMMITTER_NAME="Squarepants, Bob";
     GIT_AUTHOR_NAME="Squarepants, Bob";
     GIT_COMMITTER_EMAIL="[email protected]";
     GIT_AUTHOR_EMAIL="[email protected]";
     git commit-tree "$@";
   else
     git commit-tree "$@";
   fi' HEAD

git filter-branch lets you rewrite Git revision history by rewriting the branches mentioned, in our case it was HEAD, applying custom filters on each revision. Those filters can modify each tree (e.g. removing a file or running a perl rewrite on all files) or information about each commit. Otherwise, all information (including original commit times or merge information) will be preserved.

HEAD is a reference to the currently checked out commit. In normal states, it’s actually a symbolic reference to the branch you have checked out.
Looking at the contents of .git/HEAD you’ll see something similar to ref: refs/heads/master.
The branch itself is a reference to the commit at the tip of the branch.


Git: Create a branch on your local machine, switch to it and then push it on the server

Following are a couple of simple commands that we use daily to create a new branch on git and push it to the git server.

The following command will create locally a new branch called branch_name and switch to it.

git checkout -b branch_name;

The following command will push the local branch you are currently switched to on the git server.
It will be made available to the server using the name branch_name.

git push --set-upstream origin branch_name;

Fedora: Start a Virtual Machine using a physical hard disk

Recently, we wanted to start a Virtual Machine running a Windows installation from a physical hard disk.

We could not find a way for GNOME Boxes to achieve this, so we installed qemu to do so.

We installed qemu using:


sudo dnf install qemu -y;

Configuring our command to start the Virtual Machine from the physical hard drive:

  • Our hard disk was identified on the physical machine as /dev/sda so we set the -hda parameter to that value.
  • Then we added the parameter -boot c to instruct the virtual machine to boot from the first hard disk.
  • The default guest start-up RAM size was 128 MiB, so we set the parameter -m to 4096 to give to the virtual machine 4GB of RAM.
  • Finally we added the -snapshot parameter which instructed the system to write to temporary files instead of the disk image files (all disk images are considered as read only).
    In this case, the raw disk image used are not written back. When sectors are written, they are written in a temporary file created in /tmp.
    You can however force the write back to the raw disk images by using the commit monitor command (or C-a s in the serial console).

In the end our command was as follows:


sudo qemu-kvm -snapshot -m 4096 -boot c -hda /dev/sda;


A couple of notes on moving a VirtualBox ‘.vdi’ disk image to a GNOME Boxes virtual machine

Recently we had a CentOS virtual machine on VirtualBox which we wanted to use in GNOME Boxes.
We copied the .vdi disk image and we used it to create a new virtual machine in Boxes.

Note A:

By doing this we realized that the system did not reuse the .vdi image.
It merely created a copy at ~/.local/share/gnome-boxes/images/ that was suitable for GNOME Boxes.
So, be sure to have enough space when doing an import like this.
You will need at least twice the space of the .vdi image to complete the migration.

Note B:

When the guest OS started the window manager crashed and it did not allow us to login.
We assumed that this issue occurred due to the VirtualBox Guest Additions that were installed on the guest OS.
As we could not login with the graphical interface, we could not verify this claim.

Fortunately, CentOS (and many other Linux distributions) allow you to switch to a console login using the key combination alt + ctrl + F3.
(There are more than one valid key combinations to do this. In some systems alt + ctrl + F4 is also valid or alt + ctrl + F1 etc).
We hoped that by trying to login via a console login, the Guest Additions would not start and the system would not crash, which luckily this was the case, and we managed to login through the console!

After we logged in, we had to remove the Guest additions. To do so we had to execute the uninstall script that was located at /opt/VBoxGuestAdditions-X.Y.Z/uninstall.sh
(X.Y.Z is the version number of the installed VirtualBox Guest Additions).

When the removal was complete, we executed sudo reboot to restart the system and unload any VirtualBox services that could be executing at the time.
Once the system completed the restart we were able to login properly from the GUI of GNOME and use our virtual machine properly.