On 2017-05-17, at 8:35 AM, matevz.lan...@borea.si wrote: > Hi, > > orphaned branch would work, but is very inconvenient for the process we have. > > we would like for some people to work on A and commit patches to A. > other people to work on B and commit patches on B. > > Once a week we would like to get all A patches propagated to B and all B > patches propagated to A. > > We would like to do that without cherry-picking as git's merge is really > fantastical and never forgets.
So: 1. You want to have a "common" "center" branch 2. You want to merge everything on A after a certain point to common 3. You want to merge everything on B after a certain point to common (i.e. -- instead of everything from "start-of-history .. A", it's "end-of-client-specific .. A") ... I'll let someone else indicate if it's possible for merge to only take portions of a history like that. And you want to merge that common back to both branches so that A's and B's updates are cross-propagated. BUT: 4. This is only for about 95% of the updates to A and B -- a few things are still going to be side specific. Is that correct? I think 4 might just kill your use of git. --- 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.
