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
