I just bought a 1000mm X-Carve and got it set up. I’m interested in improving the software situation between GRBL and the variety of G-Code senders available, since it’s all open source and I am a software engineer. GRBL has made incredible progress in the 1.1 release, for example. I want to understand how feasible it is to upgrade my X-Controller.
Leading up to the 0.9j tag, upstream commits are merged into the fork by @JeffTalbot, and it’s still easy to track the differences. This is great!
Right after that, there is a monolithic commit 6acac9 with the message “Updated to 1.0c”. This appears to be “merging” a bunch of subsequent upstream changes. However since it was done as a regular commit, there is no merge information. As a result, the git lineage of this repo is forever diverged from the upstream repo. This is pretty unfortunate for anyone trying to make sense of the changes, and will make it difficult to keep the fork up-to-date with upstream. It will get worse over time, as the last common lineage moves further and further into the past.
@BartDring, @JeffTalbot, @paulkaplan, @EricDobroveanu: Is there any possibility of fixing this repo while it’s still feasible? It would require rewinding to the 0.9j tag, and the re-applying the dozen-or-so commits after that either by merging (for upstream commits), or cherry-picking (for your README commits).