Wijzigen van de auteur

De eerste keer dat je git gebruikt, zou je jezelf moeten identificeren door je gebruikersnaam en je mail adres op te geven. Dit omdat deze gegevens in elke commit verwerkt wordt.

Dat kan gedaan worden op systeem niveau door:

Soms wil je een ander mail adres hebben voor een ander project, dus in een andere repository. Dat kan door in die repository de global optie weg te laten:

Ik gebruik dit vaak, omdat mijn open source werk met een ander mail adres gedaan wordt, dan mijn echte dagdagelijkse job.

Maar meestal vergeet ik de eerste keren wel eens om mijn mailadres goed te zetten, zeker als ik de repository nog eens clone. Gelukkig kan dit allemaal ook ongedaan gemaakt worden, afhankelijk van de situatie.

Stel dat enkel de mail van de laatste commit gewijzigd moet worden. Dat is de makkelijkste manier, dan moet je enkel het volgende typen:

Nu kan je de commit message saven en alles is in orde.

Stel nu dat er enkele commits gewijzigd moeten worden. Dan is er een iets complexere methode. Interactieve rebase is onze oplossing deze keer:

Na dit commando komt een editor naar boven en nu kan je de commits wijzigen die je wil wijzigen. Kies dan ook voor de edit optie van de commits die je wil wijzigen, dat is de optie e. Het process start daarna en stopt bij een commit message. Dan moet je het volgende ingeven:

Save het en ga verder met de rebase:

Nu is de auteur gewijzigd. Een beetje meer werk, maar alles is dus mogelijk.

Disable fast forwarding in git

In git is er een optie om fast forwarding niet meer te doen tijdens een merge:

In ons team is de afspraak om nooit fast forwarding te gebruiken, dus is het handig dat deze optie nooit meegegeven hoeft te worden. Dit kan door een configuratie parameter:

Nadat je dit commando hebt gegeven, zijn alle merges voortaan zonder fast forwarding.

Swiping op een touch screen

Ons project had al een paar maanden een probleem met onze machines. Niet echt met de machines op zich, maar met het touch screen. Onze interface gedroeg zich namelijk anders als we met onze vinger swipeten als dan dat we het met onze muis deden, meer bepaald tijdens een drag en drop. Het probleem was dat als we van links naar rechts bewogen, dat we dan altijd op de vorige pagina terecht kwamen. Als we daarna dan andersom swipeten, dan kwamen we terug in de oorspronkelijke pagina.

Onze user interface is eigenlijk een web interface en we draaiden met chrome als browser. Dus het swipe gedrag was alsof we op de back en forward knop drukten in de browser. En dat was nu net niet de bedoeling.

Onze klanten mogen eigenlijk niet weten dat we met een webapplicatie werken, dat hebben zij trouwens geen nood aan in een fabriek. Dit is dus echt wel gedrag dat we niet willen.

Ik had al gekeken in de opties van Chrome zelf, maar nooit een oplossing gevonden. Toen vond ik een oplossing, chrome of chromium opstarten met een command line switch:

Deze oplossing vond ik op de pagina van Peter Beverloo. Hij heeft trouwens nog meer command line opties op zijn pagina gezet. Neem maar eens een kijkje op Peter Beverloo’s pagina.

Zo zie je dat ook een tester bugs kan oplossen, want niet alle bugs zitten in code.

License To Kill

During the setup of a framework with protractor tests, I had a problem. I ad it before, but at that time I did not find a solution. The intention of the framework was to run on our integration server. After each commit of a developer (or me), the tests should run. At this moment they can run after each commit, because it is not taking that long yet. Later it may happen that some tests should run at night or so.

But to perform the integration tests, a backend and some other application should run. Our backend is interacts via html with the user, but also interacts with hardware. The problem was not starting up all this, but tearing down. This because it is legacy code and shutting down is not implemented. This means that the process should be killed by jenkins.

But because our environment uses a lot of batch scripts, jenkins does not halt the backend if a test job is done. This means that I had to create a script to kill the backend after all tests has been running.

I did know how to do that on a unix like environment, but not in a windows environment. And now we are running all our code on windows. A long search later, I found that there is in windows also a command that can kill applications.

After this command was placed in a batch file, jenkins can run all tests without the fear that sometimes the backend is hanging after a test job.

How do I show the current revision

Our code is located in a git repository. If I want to know what is the current revision, I can use git log. Look then to the output on the screen and you can get a hash of the current revision. There are alternatives. Git log has many options that are not known by everybody.

How can I show the short hash of the current revision?

The command is however too large to remember. I am lucky, because I can use the alias command, so I can create an alias that I can remember. To have the alias globally known on my system, the option –global is handy.