@MakerMadeCNC would you be willing to consider merging the git history of grbl back into the MaslowDue firmware? This is a complicated question, so I though others may want to chime in.
The Problem
The MaslowDue firmware is based on grbl and looks to fork off from grbl at commit ‘332acad’. Sadly, when this fork was made, it wasn’t done with git so the commit history of grbl is no longer present.
My concern is that the MaslowDue firmware now diverges from grbl not only in the added support for the maslowcnc, but also in bug fixes and changes made to grbl since we forked. There have been 8 commits made to the grbl code since we forked. Including fixes for gcode interpretation.
By continuing the way we are, we lose what I see as one of the prime benefits of using grbl, specifically that we can rely on a large community for the generic cnc controls, the majority of the code. Leaving our community only responsible for our maslow specific features, a small fraction of the code.
The Fix
Sadly, the fix for this is not graceful, but the ability to achieve it only gets worse as more people fork the MaslowDue code and start writing commits.
I have an intermediate level of skill with git, so if someone more advanced than me has an suggestion, please speak up.
My solution uses two branches:
-
grbl-tracking - This would be used to track grbl as close as possible. It would look as follows
- Checkout grbl at the ‘332acad’ commit
- Apply a few commits to bring grbl close to what our codebase looks like.
- Specifically, rename C to CPP, and delete a few files from grbl
-
master - Continues to be where all MaslowDue release code relies and is committed to. However, master would need to be rebased!! I add the exclamation marks because rebasing will mess up anyone who is working on a commit and will certainly confuse git novices. All of it is fixable in git, but it isn’t super ideal. The master branch would initially be rebased off of the grbl-tracking branch, which would bring all of the prior grbl history into our repository.
Going forward, we would continue to use master as we do today.
Any new commits to the grbl project would first be merged into the grbl-tracking branch and then the grbl-tracking-branch would be merged into master after fixing conflicts.
Why two branches like this
- Changing the file names really messes up git. It catches some of the renames, but not all.
- Keeping grbl-tracking separate makes it easy to spot what grbl commits have not been added into our master branch.
That said, the grbl-tracking isn’t technically necessary after we do the rebase. We could ignore it and merge new grbl changes directly into master, but from my limited testing, this is a bit hard because of the file name changes and the tracking branch might make it easier to keep track of in our heads.
Sadly, in testing, it seems like we are going to see a far amount of conflict resolution, but so far it has been manageable and given the changes done (dropping the compile variables for spindle, M7, and line numbering seem like unnecessary changes that only cause continual conflict resolution), I think unavoidable.