I have the same problem with pncconf.The best seems to be to merge the branches immediately after pushing. If you merge whether you did work in master or 2.7 then anyone merging after you should have little problem. Of course hopefully there are no other difficult conflicts to deal with. Usually it's fairly straight forward.
Chris M ----- Reply message ----- From: "Niemand Sonst" <nie...@web.de> To: "emc-developers@lists.sourceforge.net" <emc-developers@lists.sourceforge.net> Subject: [Emc-developers] gmoccapy - differences between 2.7 and master Date: Wed, Feb 22, 2017 9:10 AM Hallo, I do agree, that we should not change the way of merging branches. I just would like to be informed if there are any merge conflicts regarding gmoccapy, as I can surely see easier than others how to fix them. Thanks for your comprehensiveness. Norbert Am 21.02.2017 um 16:42 schrieb Jeff Epler: > Hi. > > I understand what you are asking for, and I think your motivation is > good. But since your suggestion impacts all developers who are fixing > bugs, we need to have a dialog about it and find a solution that serves > > The crux of the issue I see is that "git merge branch-A" when on > branch-B always merges *ALL* commits that are on branch-A and not yet on > branch-B, and our workflow is to merge 2.7 to master "from time to time" > in order to get all the bugfixes and minor enhancements in the > development version. > > This workflow seems to function well for most parts of LinuxCNC, and I > would like to preserve it. Other workflows, such as using cherry-pick > to make similar changes in 2.7 and master, put extra responsibility on > *all* developers who make changes to 2.7, and increase the risk that a > change that SHOULD have been made in 2.7 and master is made only in > master. > > Instead, I'd rather search for some guidelines and strategies that will > rarely impact developers who are fixing bugs in linuxcnc that are not > related to gmoccapy. However, I think it's inevitable that this will > impose some extra duties on developers pushing fixes to gmoccapy bugs in > 2.7. > > Basically, I propose the following workflow for fixing gmoccapy bugs > differently in 2.7 and master: > * Make the appropriate change in 2.7, test and push > * Switch to master branch > * Merge 2.7 to master with but don't commit. Typical commandline: > git merge --no-commit origin/2.7 > * Discard gmoccapy changes, regardless of whether they are conflicts. > Typical commandline: > git checkout --ours -- \ > configs/sim/gmoccapy \ > docs/src/gui/gmoccapy* \ > docs/src/gui/images/gmoccapy* \ > share/gmoccapy \ > src/emc/usr_intf/gmoccapy \ > src/po/gmoccapy > [note use of the shell line-continuation character "\" to avoid long > lines in this e-mail] > * test, commit, and push master branch > * If applicable, make the gmoccapy appropriate change/bugfix for master > branch and push that > > For developers not working on gmoccapy, the only change in the workflow > is that, in case a merge conflict is seen and it names a gmoccapy file, > to contact Norbert (or any fellow gmoccapy developers he cares to > designate) instead of trying to resolve any merge conflicts themselves. > > There are probably other ways to accomplish this goal; the workflow for > fixing gmoccapy bugs in 2.7 that I outline above is just the first > method I thought of. Let's continue this dialogue and find the solution > that seems to have the least complexity. > > Jeff > PS renaming files won't help, because in at least some cases git is > smart enough to automatically find the renamed file and apply the change > to it (this can be disabled by 'git merge -Xno-renames' but I wouldn't > want to require this, since it means we also couldn't do "good renames" > but could only use renaming as a way to break automatic merging) > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
