A small word of caution/care. If I understand correctly, the `git merge -s ours` may not do quite what you expect. If the differences apply cleanly then there is no recourse to any of the `-s ours` strategy. It is only if there is a conflict that the strategy comes into force. This means that you may have merged in content that should not be there.
The alternative approach is possibly, as I understand it, the use of `git rerere` which maintains a database of how to resolve the conflicts, so you don't have to remember. This should then be used in conjunction with the `git cherry-pick` of the particular local branch fixes, which need the same old remembered resolutions every time. Ultimately, I've not seen a good exposition of how to manage your (rather common) situation that captures all the local nuances. It almost needs a commit footer that marks specific commits as special to a particular branch and indicates what merge policy to use! Another alternative is to look at how Git for Windows has to cope with the upstream git, and the use by @dscho of his 'garden-shears' script which continuosly rebases the GfW fixes on top of the every changing upsteam while retaining old history and tags (of gfw) on the same lead branch. Not as pretty as you might hope, but it shows what can be done. Philip top four links of http://www.lmgtfy.com/?q=git+rerere+usage https://git-scm.com/docs/git-rerere https://git-scm.com/blog/2010/03/08/rerere.html https://hackernoon.com/fix-conflicts-only-once-with-git-rerere-7d116b2cec67 https://chuva-inc.com/blog/fast-tip-enable-git-rerere-right-now ----- Original Message ----- From: matevz.lan...@borea.si To: Git for human beings Sent: Wednesday, May 17, 2017 11:22 PM Subject: Re: [git-users] keeping two branches with partially different history in sync Hi Michael, thanks for your help, I would give up otherwise, but now I managed to get this working with a special git merge script that automatically performs merge from A to B and vice versa by ignoring (with git merge -s ours) all opposite commits created by automated merge script (by itself), Also with "git merge -s ours" we can select which parts of the history we want to carry forward and which parts not. After performing single merge with -s ours for certain part of the history git will no longer complain about that in future merges (even normal merges) as it has already marked it as merged. regards, Matevz -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
