Thanks for speaking up about the problem as soon as you realized it. I have temporarily locked the "master" branch on github until this problem is resolved.
I understand that the idea of force-pushing master to 1d836df^ before the problem was discussed and dismissed (on IRC?). I did not see this discussion. Seb and I have each prepared PRs that approach fixing the problem. I have a third, non-pull-request suggestion. https://github.com/LinuxCNC/linuxcnc/pull/2250 -- Seb re-cherry-picks work from 2.9, excluding doc work that did not apply cleanly. This would mean the doc work is lost from master if nobody else steps up to cherry-pick and pull request the changes to master too: https://github.com/LinuxCNC/linuxcnc/pull/2251 -- I merge 2.9 into 1d836df^ (git notation for "the commit before 1d836df), doing my best to take the better side of each conflict in the documentation (usually it was pretty clear; a total of 4 files had conflicts), then merge 1d836df with the "ours" strategy (to effectively discard its version of the changes), and then cherry-pick commits subsequent to 1d836df, only one of which introduced changes. This hopefully catches the majority of doc work, but I merely selected one side or the other of the doc changes, rather than carefully merging them word by word. The third suggestion is to use this as the moment to adopt the github standard "main" branch name, instead of the deprecated branch name "master". I would prepare a new branch similar to #2251, but NOT merge 1d836df in it, and push this as "main". Besides fixing things in one of these ways, I think we should strongly consider using github "branch protection", so that any change to main and a "branch that looks like a version number" must go through the pull request process. This doesn't catch all problems, and it would require folks to step up as pull request reviewers, but it might have avoided this problem. I'll check back on this thread as well as the developers IRC channel to see if a consensus develops and then implement it. Because this is blocking ongoing work it's problably better to resolve it in a timely fashion than to spend a long time figuring out the best possible resolution. It sounds like Seb is not available for the rest of the week-end fwiw. Jeff _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
