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
