Monthly Snap November


 
Remember one month ago? The first talks were about to start soon, you had your first coffee, enjoyed the rich Holiday Inn breakfast, took your journal, in which you had your plan for the day scetched, you were happy to meet an old friend in the hallway on your way to Saal Jacobi, where Bernd Erk was preparing to kick-off OSMC. …
OSMC – good times! Take some of its spirit with you into the cold and dark december days and let it warm your heart like a cup of hot Christkindlesmarkt mullet wine.

Form OSMC to Open Infrastructure

How? Make yourself a cup of hot wine and read through OSMC 2018 – Day 1 and OSMC 2018 – Day 2 by Dirk, or OSMC 2018 – or: The Thirteen-Star Conference, in which our attendees share their experiences. Read Michi’s Hackathon stories and Dirk’s report about OSCAMP on Puppet. You’re more of a visual type?  Browse through our OSMC Archive and find all the videos, pics and slides.
Right after OSMC our NWS-Team hit the road to Berlin for OpenStack Summit. Check out their managed Open Infrastructure service at nws.netways.de – now with MyEngineer support!

Icinga Seminar & Berlin Camp

Lennart Betz continues his blogpost-seminar Icinga 2 – Monitoring automatisiert mit Puppet Teil 9: Profile and Teil 10: Profile Part II. Join the Icinga community in 2019: Icinga Camp Berlin: Call for Papers is running until Decemeber 31! Find all November Icinga updates here.

For the tech hearts

Achim tell you to Get your RadosGW metrics into Ceilometer. Loei explains the use and functionality of RFID & NFC. Niko shares Neuheiten beim IntelliJ-Update. Tim knows Ceph Mimic | Using loop devices as OSD
In git gud! Henrik tells the story of: How I Learned to Stop Worrying and Love my Code. Noah introduces you with GitKraken to a nearly perfect Git-Client, while Johannes shares another useful tool: PDF manipulieren mit pdftk.

Presents

In November Silke announced Black Friday mal ganz in Orange – Es darf gespart werden und Die neue Generation der SMSEagle NXS-97xx Linie stellt sich vor. It‘s always a good idea to check our Shop for special offers. Especially if you are looking for Christmas presents. In that sense: Entschleunigung vom Weihnachtsstress bei Netways!
Have a wonderful December and Christmas season! Stay tuned!

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

GitLab training v2.3.0 released

We really had an awesome time in the last 2 days practicing Git and GitLab. With all those ideas from a training, I’ve updated the material and tagged v2.3.0.
This release includes bugfixes for “hard to understand” slides and continues with new features added to the training, done “on the fly” yesterday: Issue boards, Web IDE with commits & CI pipeline jobs, improved workflows with milestone, issue and merge request handling and much more.
Cannot wait to practice this? Get your ticket for our GitLab training soon enough! 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Microsoft and GitHub – merge conflict?

For some time it has become clear that Microsoft is going to take over GitHub. As far as official sources can be trusted, GitHub will stay independent although a new CEO (Nat Friedman) will be introduced after the Microsoft takeover.

This question over GitHub’s future independence has raised a lot of skepticism within the developer community and many are considering moving their projects away from GitHub to a different location.
One alternative in this case could be GitLab. GitLab does not only have an online platform but it can as well be installed on your own hardware. Furthermore, it is an extremely solid piece of Open Source software you can fully rely on. This is also shown by the makers of GitLab themselves as they release updates each month – rolling out bug fixes, security updates and many recommendations regarding the use and configuration of your instance.
For those who would like to have their own GitLab instance, NETWAYS offers two options:
First one is available on our NETWAYS Web Services platform where we offer user-managed, hosted GitLab instances as Community or Enterprise Edition. The user does not need to take care of anything regarding installation or maintenance of his GitLab, but can directly go into production in no time with only a few steps needed. You as a customer are also free to decide for how long you would like to run your instances as any app is monthly callable. Furthermore, we regularly update these container based apps and monitor their health  for you. As a customer, you can register on NWS and try all the apps we offer 30 days for free.
The second product we offer is done by NETWAYS Managed Services which is exactly what it is called: With managed hosting you can get a virtual machine in our cloud or rented hardware running a full GitLab, either as Community or Enterprise Edition. You can choose the underlying ressources and we will do the rest for you, like installation with individual parameters and health monitoring. With managed hosting, our customers also have the choice to go full 24/7 support with “emergency” calls.

Nicole Lang
Nicole Lang
Account Manager

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

May Snap 2018


Hello Sunshine!!
With the little shower from the dearly sky in May, Fabian talks about the release of Ubuntu 18.04 LTS “Bionic Beaver”. And there is so much more for you to discover: Get all infos about Updating with Ansible from Thomas. Keya invites all monitoring lovers to Be a Speaker at the OS Monitoring Conference 2018 and Tim reveales some useful tips and tricks: Change your AD Password easily via OWA.
Keya announces NETWAYS’s Upcoming Training #Summer 2018 and We are ready, Are you Ready for the OSCamp? – Find out more! Nicole gives a fun insight in her experiences with Icinga 2 in Noob vs. Icinga 2, while Jennifer shares her experience with Training with NETWAYS in Software development and why it is worth doing. David packs a Handful of (Vagrant) Boxes. Everyone at NETWAYS is clapping. What for? Daniel let’s you know more about the Power Challenge #1min.care. Or you can follow Sebastian on the Road to OpenStack.
Michael reports about Releasing our Git and GitLab Training as Open Source, and Gabriel compares Rocket.Chat vs Slack, while Afeef reveales what happened in the fun and informative Apprentice Project week 2018. Last but not least, Keya has one really important reminder for you: Grab your OSDC Ticket! Last tickets alert!
 

Keya Kher
Keya Kher
Marketing Manager

Keya ist seit Oktober 2017 in unserem Marketing Team. Sie kennt sich mit Social Media Marketing aus und ist auf dem Weg, ein Grafikdesign-Profi zu werden. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.  

Releasing our Git and GitLab training as Open Source

Development is super fast these days, there are many tools and integrations to make it more comfortable. One of the version control systems is Git, next to well-known SVN and CVS. Git got really pushed by GitHub and most recently GitLab which provide entire collaboration suites. Nowadays you not only commit code revisions/diffs, you can also test and deployment changes immediately to see whether your code is good on defined platforms or breaks. Issue and project management is put on top and makes it very easy to collaborate.
Continuous integration (CI) allows for deeper code quality too. Add code coverage reports, unit test results, end2end tests and actually build distribution packages with tests on many platforms included. In addition to CI, continuous deployment (CD) adds the icing on the cake. Once CI tests and package builds are fine, add a new build job to your pipeline for automated deployments. This could for example push updated RPM packages for your repository and immediately install the bugfix release in production on all your client hosts with Puppet or Ansible.
You can do all of this with the ease of GitHub or your own hosted GitLab instance (try it out in NWS right now!). Don’t forget about the basics for development and devops workflows:

  • Untracked files, staging area, … what’s within the .git directory?
  • What is a “good commit“?
  • I want to create patch for an open source project – what’s a “pull request“?
  • Workflow with branches?
  • A developer asked me to “rebase your branch against master” and “squash the commits” … what’s that?

Our Git training sessions have been renewed into a two day hands-on session on Git and GitLab. Many of us are using Git on a daily basis at NETWAYS, in addition to GitLab. Knowledge which we share and improve upon. The training starts with the Git basics, diving into good commits, branching, remote repositories and even more. Day 1 also provides your own NWS hosted GitLab instance.
Starting with day 2, you’ll learn about development workflows with branches and real-life use cases. Continuing with CI/CD and generating your own Job pipeline, and exploring GitLab even further. We’ll also discuss integrations into modern development tools (Visual Studio, JetBrains, etc.) and have time to share experiences from daily work. I’ve been working with Git since the beginning of Icinga more than nine years ago.
We have open-sourced our GitLab training material. We truly believe in Open Source and want make it easier for development and contributions on your favourite OSS project, like Icinga.
You are welcome to use our training material for your own studies, especially if you are an open source developer who’s been learning to use Git, GitLab and GitHub. For offline convenience, the handouts, exercises and solutions are provided as PDF too.
Many of the mentioned practical examples and experiences are only available in our two day training sessions at NETWAYS so please consider getting a ticket. There’s also time for your own experience and ideas – the previous training sessions have shown that you can always learn something new about Git. You can see that in the Git repository and the newer Git commits, where this feedback was added to the training material ❤️
See you soon at the famous NETWAYS Kesselhaus for a deep-dive into Git and GitLab!
Please note that the training material is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

GitLab Security Update Reviewed

NETWAYS schreibt die Sicherheit ihrer gehosteten Kundenumgebungen groß – daher kamen auch wir nicht um das Sicherheitsupdate in den GitLab Community Edition und Enterprise Edition Versionen herum.
GitLab machte Mitte März öffentlich, dass man auf eine Sicherheitslücke sowohl in der Community als auch in der Enterprise Edition gestoßen sei. Dabei soll es sich um sogenannte Server Side Request Forgery (SSRF) handeln, was Angreifern unter anderem den Zugriff auf das lokale Netzwerk ermöglich kann. GitLab löste dieses Problem nun durch ein Software Update und den Einbau der Option “Allow requests to the local network from hooks and services“, die per default deaktiviert ist und somit den Zugriff der Software auf das lokale Netz unterbindet.
Das Update auf eine neuere Version ist für viele Nutzer eine gute Lösung – allerdings nur, wenn diese keine Webhooks oder Services, die das lokale Netz als Ziel haben, nutzen. Denn wenn plötzlich die Webhooks und Services nicht mehr funktionieren und weder der Admin noch der User weiß, dass man bei der obigen Option einen Haken setzen muss, dann beginnt erst mal die Fehlersuche.
Fazit: Wer unbedingt auf Webhooks und ähnliches angewiesen ist, muss wohl oder übel vorerst mit der Sicherheitslücke leben.
Eingebaut wurde der Fix in folgende GitLab CE und EE Versionen: 10.5.6 / 10.4.6 / 10.3.9. Eine vollständige Übersicht an Releases findet man hier: GitLab Release

Managed Hosting bei NETWAYSGitLab CE und GitLab EE

NETWAYS Web Services – 30 Tage kostenfreies Testen von GitLab CE und GitLab EE

Nicole Lang
Nicole Lang
Account Manager

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

NETWAYS Web Services: GitLab EE


The NETWAYS Web Services Team is proud to announce the arrival of a new product: Customers can now have their GitLab EE instances hosted on our NWS platform.
Version control has become one of the most important aspects of everyday work life and has gone far beyond being only used by development teams. Many more use cases for version control have been created so far and are still to come. Even small teams are already using GitLab CE for controlling their workflows which is one of our reasons to offer this software as a hosted product.
After realizing that many users needed higher performance for increasing their productivity, we decided to add GitLab EE to our portofolio as it offers many more options and features than the CE version – without having to take care of the underlying hard- and software layers needed for running the application.
The process of hosting GitLab EE with us is almost as simple and comfortable as with all our other products – create an NWS account, choose a product and get started. GitLab EE makes a little exception for it is an Enterprise product and therefore customers need to provide a license acquired at GitLab. You can be sure that all features included in your license will be available in your NWS container right from the start.

This license is the only aspect the customer needs to take care of – NWS will provide all the comfort our customers already know from our other products, like maintenance works, updates, patches and a stable and well monitored platform underneath.
 
All those who do not want to worry about their version control should take a look at our attractive and scalable plans as well as individually sized solutions for hosting GitLab EE. More information can be found on our NWS homepage, in our GitLab EE section or by contacting us via the NWS livechat.
Important note: All NWS products are up for a 30 day free trial!
 

Nicole Lang
Nicole Lang
Account Manager

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Contributing to projects on GitHub

GitHub Logo
Today I want to share my workflow for contributing to projects hosted on GitHub because I believe it works very well for me and I regularly contribute to various projects. Of course most of this also applies to other hosted Git platforms like GitLab. It will not involve any Git magic as there are other posts to do that. So let’s use adding a check command to Icinga 2 as my example.
The obvious first step is finding the Git repository for the project and reading contribution guidelines because there are some projects which aren’t hosted on GitHub and some have additional requirements like submitting an issue in addition to a pull request. You should always familiarize yourself with and stick to those policies if you want your pull request to be accepted. For Icinga 2 there currently aren’t any additional project-specific guidelines.
Your next step is to create a fork on GitHub and clone the repository. So in the GitHub web interface click on “Fork” and select your own account (or company account as long as you are allowed to push). Once you’ve forked the repository you can check out a local copy using the following command:

git clone git@github.com/dgoetz/icinga2.git

Afterwards you should add another “remote” for the original Git repository in order to be able to update your own repository with changes from the upstream project:

cd icinga2/
git remote add upstream git@github.com:icinga/icinga2.git

After these initial steps you can create a Git branch for your feature or bug fix. Using the “master” branch for pull requests is strongly discouraged because things tend to get complicated once you have more than one pull request. Another recommendation is to use branch names that match the upstream repository’s style. This however is not a hard requirement:

git checkout -b feature/expand-check-foo

This also automatically switches to the newly-created branch which means you can now start to edit files for your pull request. Once you’re done you can add them to the Git index and create a commit. Typically upstream projects have guidelines for this, so do not forget to include documentation, make only one commit out of your work (perhaps by squashing) and so on.

vi itl/plugins-contrib.d/network-components.conf
vi doc/10-icinga-template-library.md
git add itl/plugins-contrib.d/network-components.conf doc/10-icinga-template-library.md
git commit -m "ITL: expanded check foo"

Afterwards push your commit to your forked repository and then create your pull request using the GitHub webinterface:

git push -u origin feature/expand-check-foo

When creating the pull request make sure to provide a detailed description of your changes and the reason why you feel that your pull request should be merged. Keep the setting checked to allow edits from maintainers. Depending on the project make sure to reference any related issues, fill in their pull request template or do whatever else they require for pull requests.
GitHub pull request
Typically once a pull request is created automated tests will be run and a review process by the project team will start, so it’s possible that you’ll be asked to make changes before your pull request is accepted. If this happens simply edit your branch to fix whatever problems were found during the review, amend your commit and force push it to your fork. This will also automatically update your pull request but you might want to provide a comment for the pull request as to what has changed:

vi doc/10-icinga-template-library.md
git add doc/10-icinga-template-library.md
git commit --amend -m "ITL: expanded check foo"
git push -f

Another commonly requested change is that you rebase your branch before the pull request is accepted. This usually happens when significant changes were made to the upstream repository while your pull request was waiting to be merged. In order to rebase your branch the following commands should be all you need, however in some cases you may also have to manually resolve conflicts:

git pull --rebase upstream master
git push -f

And of course you will sometimes want to create additional pull requests. For these make sure to start with a new branch based on the upstream repository:

git checkout master
git pull upstream master
git checkout -b fix/check-bar
...
git push -u origin fix/check-bar

So, this is it, this is my basic workflow for easy contributions on GitHub. I hope it helps you to get involved with your favorite projects and your fixes and features to get upstream. If you prefer to do all step in the command line, you can have a look at GitHub’s command-line wrapper for git hub. If you need more general Git knowledge I recommend the Git book and our training. If you need a GitLab system to play around, have a look at our NWS platform.

Dirk Götz
Dirk Götz
Senior Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

It's magic: git squash

training_gitA common technique for feature development with Git is to start with a new feature branch. You’ll continue to add and commit changes into that branch and at some point in time you want to merge the many work-in-progress commits into one. The Git terminology references that as “squash“.
Another common best practice is to use the Git forking model you are probably familiar with on GitHub. You’ll fork your own repository, start adding a new Icinga 2 ITL CheckCommand definition, later on you are adding the missing documentation bits. Then you’ll send a pull request to the upstream repository. Developers will review your changes and probably ask you to rebase and squash your commits into one commit.
Let’s just try that.

michi@mbmif ~/coding/icinga/icinga2 (master) $ git checkout -b feature/itl-checkcommand-13079
<change, add, commit>
michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git l
* ed6a68f- (HEAD -> feature/itl-checkcommand-13079) Docs: Fix phrasing (5 minutes ago)
* ce90e16- Add documentation for logfiles (5 minutes ago)
* 5a31d9e- Add CheckCommand "logfiles" (6 minutes ago)
* dc29924- (origin/master, origin/HEAD, master) Deprecate the client 'bottom up' mode w/ node update-config (2 hours ago)
...

Now I want to merge that feature branch back to the master. Our development guidelines require me to squash the three commits first.
Generally speaking you can use the interactive “git rebase -i” command here. It requires an additional parameter about the commits we will be editing, counting from HEAD back in the history. In my case I want to edit HEAD minus 3 commits.
The interactive mode will open the configured editor, vim in my case.

michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git rebase -i HEAD~3
pick 5a31d9e Add CheckCommand "logfiles"
pick ce90e16 Add documentation for logfiles
pick ed6a68f Docs: Fix phrasing
# Rebase dc29924..ed6a68f onto dc29924 (3 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

Git informs us about the possible options here. I could just use “edit” which iterates over the commits, stops for amending the commit message and/or the commit changes itself.
I want to squash the commits. This requires the base commit (usually the first one) to stay on “pick” while the others are changed to “squash”.

pick 5a31d9e Add CheckCommand "logfiles"
squash ce90e16 Add documentation for logfiles
squash ed6a68f Docs: Fix phrasing

This will squash the commits one by one onto the last picked one. Save the changes and continue.

# This is a combination of 3 commits.
# This is the 1st commit message:
Add CheckCommand "logfiles"
# This is the commit message #2:
Add documentation for logfiles
# This is the commit message #3:
Docs: Fix phrasing
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Wed Nov 23 17:19:55 2016 +0100
#
# interactive rebase in progress; onto dc29924
# Last commands done (3 commands done):
#    squash ce90e16 Add documentation for logfiles
#    squash ed6a68f Docs: Fix phrasing
# No commands remaining.
# You are currently editing a commit while rebasing branch 'feature/itl-checkcommand-13079' on 'dc29924'.
#
# Changes to be committed:
#       modified:   doc/10-icinga-template-library.md
#       modified:   itl/plugins-contrib.d/logmanagement.conf

Edit the commit message (comments starting with “#” will be ignored) and make it a good one (also something you learn in the training session ;)).

Add CheckCommand "logfiles"
refs #13079

Save and continue.

[detached HEAD f1445eb] Add CheckCommand "logfiles"
 Date: Wed Nov 23 17:19:55 2016 +0100
 3 files changed, 8 insertions(+)
Successfully rebased and updated refs/heads/feature/itl-checkcommand-13079.

Verify the changed commit history.

michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git l
* f1445eb- (HEAD -> feature/itl-checkcommand-13079) Add CheckCommand "logfiles" (3 minutes ago)
* dc29924- (origin/master, origin/HEAD, master) Deprecate the client 'bottom up' mode w/ node update-config (2 hours ago)

When you are updating your remote repository you’ll need to override the remote history with the local history. Be careful when using “-f”!

michi@mbmif ~/coding/icinga/icinga2 (feature/itl-checkcommand-13079) $ git push -f origin feature/itl-checkcommand-13079

Voilà – our Git commit history is now rebased and squashed.
This example works in a similar fashion with a forked repository on GitHub, thus requiring you to update your PR then.
Hint: I’m using Git shell integration as well Git aliases here (“git l”). We’ll dive into these topics in our Git training too 🙂

$ git config --list | grep 'alias.l'
alias.l=log --graph --pretty=format:'%Cred%h%Creset-%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative --
Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...

Sharing Git patches in a different way

training_gitSometimes it is necessary to share git patches locally. Either you cannot push it to the public domain in a feature or master branch or you simply don’t have an internet connection – for example while working in a customer VPN reproducing issues locally.
You could hope for XMPP sending patch files or any other local transport. But if you don’t want to add, commit, format-patch and send a patch file you’ll obviously go for plain text copy paste of a ‘git diff’ output. Editors and messengers tend to destroy the tab indent. Now what?
base64 encoding to the rescue.

michi@mbmif ~/coding/icinga/icinga2 (master) $ git diff | base64

Send the blob to your colleague who can easily apply it. Example on MacOS:

michi@mbmif ~/coding/icinga/icinga2 (master) $ base64 -D | patch -p1

Or if written to a temporary file:

michi@mbmif ~/coding/icinga/icinga2 (master) $ base64 -D < patchfile | patch -p1

More about working with Git and applying patches can be learned in our Git training sessions. There’s also a Git workshop during this years OSMC 🙂

Michael Friedrich
Michael Friedrich
Senior Developer

Michael ist seit vielen Jahren Icinga-Entwickler und hat sich Ende 2012 in das Abenteuer NETWAYS gewagt. Ein Umzug von Wien nach Nürnberg mit der Vorliebe, österreichische Köstlichkeiten zu importieren - so mancher Kollege verzweifelt an den süchtig machenden Dragee-Keksi und der Linzer Torte. Oder schlicht am österreichischen Dialekt der gerne mit Thomas im Büro intensiviert wird ("Jo eh."). Wenn sich Michael mal nicht in der Community helfend meldet, arbeitet er am nächsten LEGO-Projekt oder geniesst...