On 2017-05-16, at 1:36 PM, matevz.lan...@borea.si wrote: > Hi Michael, > > that would work normally, however we have a problem that we can not keep > common master and we need to split the master to A and B. The base code > changes are huge and there is no way for us to ever merge A and B branches > completely. > However the commits applied to A and B are compatible with both branches. > Cherry-picking everything after conflicting commits from A to B and B to A > would work, but we would like to avoid cherry-picking as it requires too much > manual checking and attention. > > regards, > Matevz
So, lets see if I understand this: You have a common source "master". You have two very large sets of changes from master, A and B. You need to apply patches to both A and B. These patches will apply cleanly to both. But these patches will not apply to the last common "master" where A and B diverged.' Is that correct so far? > > > > On Tuesday, May 16, 2017 at 6:57:16 PM UTC+2, Michael Gersten wrote: > > If so, I think that either doing merges from master to A and B, or rebasing > the few commits of A and B to the tip of master as you go, is the right > answer. > > Am I correct in thinking that A and B are per-client customizations to your > main code? > > > -- > 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. --- Entertaining minecraft videos http://YouTube.com/keybounce -- 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.
