There are many tutorials online which describe how to use git bisect. Here's one: https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search
You would simply configure and build a RIP version of linuxcnc at each step of the binary search, then test it for whether the bug is present or not. The end result, if your testing procedure was correct, is that you know at what commit the behavior you are testing changed. Unfortunately, in lengthy bisects without a fully automatic testing procedure, I often make mistakes and initially let blame fall on an incorrect commit. I also don't have any theory why specifying one axis name vs two axis names would reliably change the behavior of the reload function. > G10 L20 P1 X0Y0 vs > G10 L20 P1 X0 which (aside from the name) seems to be the only difference between the two bits of code. As I tired to indicate in my initial reply in this thread, I am not particularly committed to making "axis remote --reload" work while an MDI is actively executing; I think this is a mistaken idea. It was an initial design decision in AXIS that a change to the active coordinate system that was *NOT* done by AXIS own touch-off would never trigger an automatic reload. Perhaps *this* is the decision that should be revisted; I would consider a patch which would optionally trigger a reload when the active g5x offset or g92 offset was changed, at the next moment that AXIS believes it is OK to perform a reload (e.g., after the MDI that generated the coordinate system change was finished) This could be controlled by an inifile option or a menu option. Probably the former would be preferable for you, so that an operator can't make the wrong setting at runtime. Jeff ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
