Our current strategy has not been always right in the past. I have occasionally had to fix merges after the fact because someone merged them wrong. (People have occasionally had to fix my merge mistakes too.) Which is not surprising considering the type of files I usually work on (XML). I have had to wait for up merges to get needed work to master. The conflicts you are talking of are probably because I put separate commits in each branch because I was tired of waiting.
Of course 2.9 to master will be easy for a while but the same problem will come back. Even more so if the Debian inclusion gives us many more pull requests from non devs. I just think that having only about 4 devs that actually do merges is not a good games plan. I presented my idea to see if anyone could show a fatal flaw of it so I appreciate the discussion/feedback. So far no fatal flaw, other then it's different. But I also recognise I'm not convincing anyone so I guess I will try to let it go :) But again thanks for the discussion, that was the most important part! Chris ________________________________ From: andy pugh <bodge...@gmail.com> Sent: November 30, 2022 10:24 AM To: EMC developers <emc-developers@lists.sourceforge.net> Subject: Re: [Emc-developers] Merge Strategy On Wed, 30 Nov 2022 at 07:38, Chris Morley <chrisinnana...@hotmail.com> wrote: > > The only solution, given our current strategy, is to wait/ask for someone > else to fix it. > This is the crux of the problem. I think that our current merge-up strategy has been right in the past and will be right again, but currently there are significant conflicts between the tip of 2.8 and 2.9. These seem to be mainly docs and the fallout of me merging 7i96S support "backwards". I think we need a one-off effort to make sure that there aren't any important bug fixes in 2.8 needed in 2.9 but in general I think that the outstanding commits should be marked as merged (for housekeeping reasons) but with the code remaining as the 2.9 version unless there is an obviously necessary fix. I think that in general this is going to mean just git checkout --ours conflicted.file but with a look at the commit description to see if a fix (possibly one different from either existing file) is needed. Here is the conflict list. Auto-merging src/hal/drivers/mesa-hostmot2/pins.c CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/pins.c Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.h CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/hostmot2.h Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.c CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/hostmot2.c Auto-merging src/hal/drivers/mesa-hostmot2/hm2_eth.c Auto-merging src/emc/usr_intf/pncconf/private_data.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/private_data.py Auto-merging src/emc/usr_intf/pncconf/pncconf.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/pncconf.py Auto-merging src/emc/usr_intf/pncconf/build_HAL.py CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/build_HAL.py Auto-merging src/emc/usr_intf/gmoccapy/release_notes.txt CONFLICT (content): Merge conflict in src/emc/usr_intf/gmoccapy/release_notes.txt Auto-merging src/emc/usr_intf/gmoccapy/gmoccapy.py Auto-merging src/emc/usr_intf/gmoccapy/getiniinfo.py Auto-merging src/emc/usr_intf/emcrsh.cc Auto-merging src/Makefile Auto-merging share/qtvcp/panels/cam_align/cam_align_handler.py CONFLICT (content): Merge conflict in share/qtvcp/panels/cam_align/cam_align_handler.py CONFLICT (modify/delete): docs/src/gui/gmoccapy.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/gui/gmoccapy.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc_es.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc_es.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc.txt left in tree. CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc-cn.txt deleted in HEAD and modified in 2.8. Version 2.8 of docs/src/getting-started/getting-linuxcnc-cn.txt left in tree. Auto-merging docs/man/man9/hostmot2.9 CONFLICT (content): Merge conflict in docs/man/man9/hostmot2.9 Auto-merging docs/man/man9/hm2_eth.9 Auto-merging debian/changelog CONFLICT (content): Merge conflict in debian/changelog Auto-merging VERSION CONFLICT (content): Merge conflict in VERSION warning: inexact rename detection was skipped due to too many files. warning: you may want to set your merge.renamelimit variable to at least 2086 and retry the command. Automatic merge failed; fix conflicts and then commit the result. pins.c, hostmot2.h, hostmot2.c, release_notes.txt, hostmot2.9, hm2_eth.9 changelog and VERSION should all be resolved by --ours. That leaves pncconf private_data.py, pnconf.py builf_HAL.py from pncconf. I think that these, too, are a result of the 7i96s support and need to be solved with --ours. That leaves some docs fixes (which are easy to understand) So, the only one that I don't know how to solve just by looking at the list is cam_align_handler.py. My proposal is to do this as (probably) the last merge of 2.8 to 2.9 and then I think that 2.9 to master going forwards will go more smoothly. -- atp "A motorcycle is a bicycle with a pandemonium attachment and is designed for the especial use of mechanical geniuses, daredevils and lunatics." — George Fitch, Atlanta Constitution Newspaper, 1912 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
