Today I learned about the dangers of forking a project repository.
Our team had forked the Wraith testing tool, a long time ago, and then made a bunch of customizations to the project, to suit our needs.
But then, as is often the case in tech, things move super fast, and — of the 1400 lines of the project — 1200 of them changed within 5 months. And of those 1200 new lines, all 1200 of them were awesome and I wanted them.
Except…..customization! We had labored on all this sweet customization of our own — I couldn’t just THROW THAT AWAY — could I?
I tried not to. First, I tried to
git merge that jazz. This was heinous. Methods had been extracted out into their own individual modules and things were failing even after 2 hours of refactoring. So then I tried to do an interactive-rebase. This was also SO HARD! Because of all the refactoring on the project side, I wasn’t really sure who’s changes to keep.
In the end, I took some great advice, made some decisions and did some fancy git work to get the latest and greatest project features, and plan to recustomize when there is time.
Lesson: Do not fork unless you are sure you want to fork.