Fix enum comparison

[jdhoek]

Ik zag bij het werken aan de voorlooplettercode twee bugs in deze code. String wordt met BuildingStatus vergeleken, en zal altijd false teruggeven. Dat zal met een refactor eens gebeurd zijn denk ik?

Enums mag je met == vergelijken in Java, omdat het singleton-instanties zijn.

[gidema]

Ik heb dit lokaal gecorrigeerd, evenals een soortgelijke bug in regel 20 waar Eclipse me op wees. Er schijnt een Eclipse plug-in te zijn waarmee ik pull requests kan verwerken, maar die heb ik nog niet aan de praat.

[jdhoek]

Persoonlijk geef ik er altijd de voorkeur aan git-zaken buiten de IDE te verwerken. Git is zo helder in het gebruik dat dit vaak veel eenvoudiger is dan het aan de IDE overlaten. Zo houd je zelf het overzicht wat er gebeurt in je repo.

Doorgaans kun je twee dingen doen met een PR:

Rebase

Als de commit in orde is, kun je je doelbranch (jouw 0.6 hier) er mee rebasen:

git checkout bug/enum-comparison
# De feature-branch bijwerken met je doelbranch:
git rebase 0.6
# Naar de doelbranch:
git checkout 0.6
# De doelbranch rebasen met de feature-branch:
git rebase bug/enum-comparison

Als een PR geen conflicts heeft, gaat dit allemaal zonder problemen. Als er wel conflicts zijn, dan vraagt git je die op te lossen, maar bij een PR mag je dat als maintainer ook aan de aanbieder overlaten.

Klaar!

Cherry-picken

Wat ook kan als de feature-branch maar een paar commits heeft (of één), is die commits cherry-picken naar je doelbranch:

git checkout 0.6
git cherry-pick 6b25ff1cb7c247999f75c82b14899d612c2a8f7a

Dit is soms eenvoudiger dan rebasen, en je behoudt er net als bij rebasen de commitmetadata mee.

[jdhoek]

Ik heb dit lokaal gecorrigeerd, evenals een soortgelijke bug in regel 20 waar Eclipse me op wees.

Die zat ook in deze PR. :)