Re: [git-users] keeping two branches with partially different history in sync
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.
Re: [git-users] keeping two branches with partially different history in sync
Hi Igor, script and sample git repo attached. 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. git-sync-repo-script.tar.xz Description: Binary data
Re: [git-users] keeping two branches with partially different history in sync
Hi Matevz, On Thursday, May 18, 2017 at 12:22:09 AM UTC+2, matevz...@borea.si wrote: > > 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), > Would you mind sharing the script, please? I`m curious to see what works for you, still struggling to comprehend what benefits merging provides in your use-case. > 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. > This is true, but this "fake merge" is usually used for single way merging only, where you`re disregarding part of the history of the branch you`re merging from (say, A), kind of declaring it obsolete/superseded by the branch you`re merging into (say, B), but keeping the reference to it. Then you can keep merging in the same direction (from A to B), having only new A commits being included in the the future merge(s) to B. But as soon as you try to merge the other way around, hoping to merge only new commits from B to A, you may be surprised by the outcome, having changes contained in your "private" B commits coming along, too, with "private" A commit changes now actually being removed inside the very A branch - a behavior you already experienced in your simple test repository. If you instead do another `git merge -s ours` but in a different direction first (from B to A), then merging the new commits found on B to A, this will work, but it kind of seems as a glorified cherry-picking...? Not sure if any advantages you`re looking for in merging, if any in this case, are worth the badly messed up history with these repetitive `-s ours` cross merges :/ Hey, but if it works for you, I guess all is good :) I`m just curious. Regards, Buga -- 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.
Re: [git-users] keeping two branches with partially different history in sync
Hi Matevz, On Wednesday, May 17, 2017 at 6:15:49 PM UTC+2, matevz...@borea.si wrote: > > I managed on simple repository with > merge -s ours > To ignore specific commits from the other side. > > However in real life repo things get broken pretty soon. A changes are > propagated to B and then back to A and are lost in A, but remain in B :-) > This is exactly what I referred to as "while possible to accomplish, may be rather confusing and greatly complicate our life down the road" in my initial reply[1]... :) [1] https://groups.google.com/d/msg/git-users/ovqx55Fv6bY/vuirLMmXAgAJ -- 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.
Re: [git-users] keeping two branches with partially different history in sync
Hi Igor, yes, I was referring to "2 messages have been deleted" I think this happened because I left Michael's email in my reply and Google was not too happy with several Youtube links in that reply. Deleting Michael's contents and only writing my reply into the message resolved. thanks, 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.
Re: [git-users] keeping two branches with partially different history in sync
On Wednesday, May 17, 2017 at 9:48:04 PM UTC+2, rh kramer wrote: > > I see no evidence your messages are being deleted from this list. Are you > referring to something else? You do know that (for some reason I don't > know) > messages that you send to most lists are either not sent back to you or, > at > least, are not displayed in typical mail clients? > Google Groups web interface shows "2 messages have been deleted" in the middle of the thread[1]. Not sure what happened, though, as no more info seems to be provided...? [1] https://groups.google.com/forum/?fromgroups#!topic/git-users/ovqx55Fv6bY -- 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.
Re: [git-users] keeping two branches with partially different history in sync
I see no evidence your messages are being deleted from this list. Are you referring to something else? You do know that (for some reason I don't know) messages that you send to most lists are either not sent back to you or, at least, are not displayed in typical mail clients? On Wednesday, May 17, 2017 11:32:31 AM matevz.lan...@borea.si wrote: > Hi, > > do you have any idea why my messages are being deleted? > > regards, > Matevz
Re: [git-users] keeping two branches with partially different history in sync
Hi, I managed on simple repository with merge -s ours To ignore specific commits from the other side. However in real life repo things get broken pretty soon. A changes are propagated to B and then back to A and are lost in A, but remain in B :-) Matevz Langus -- 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.
Re: [git-users] keeping two branches with partially different history in sync
Then I think it should be possible. Just need to know how to tell merge to only look at changes from "start of A's mergeable's changes to tip of A". And I don't know that. Or: Should be possible Limit merging to a range How do you do that? (Haiku because ... haiku) On 2017-05-17, at 8:54 AM, Matevz Languswrote: > Hi, > > 1,2,3 yes. > > 4: no, 100% of updates go from A to B and vice versa > > thanks, > 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. --- 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.
Re: [git-users] keeping two branches with partially different history in sync
Hi, 1,2,3 yes. 4: no, 100% of updates go from A to B and vice versa thanks, 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.
Re: [git-users] keeping two branches with partially different history in sync
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.
Re: [git-users] keeping two branches with partially different history in sync
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. thanks, 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.
Re: [git-users] keeping two branches with partially different history in sync
Hi, do you have any idea why my messages are being deleted? 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.
Re: [git-users] keeping two branches with partially different history in sync
AHH... So what you want is a new, orphaned branch of changes, and you want to merge that new branch into both A and B. Correct? I'll let someone that knows how to set that up chime in. On 2017-05-17, at 6:33 AM, matevz.lan...@borea.si wrote: > Hi, > > > 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? > > CORRECT. 99% of cases they will apply cleanly on both, 1% with conflicts. > Some of the patches might even apply to "old common master", but it would not > compile or not work if it would compile. Old master is a third branch we do > not want to maintain because it is useless without very large sets of changes > in A and B. > > 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. --- 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.
Re: [git-users] keeping two branches with partially different history in sync
Hi, > 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? > CORRECT. 99% of cases they will apply cleanly on both, 1% with conflicts. Some of the patches might even apply to "old common master", but it would not compile or not work if it would compile. Old master is a third branch we do not want to maintain because it is useless without very large sets of changes in A and B. 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.
Re: [git-users] keeping two branches with partially different history in sync
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.
Re: [git-users] keeping two branches with partially different history in sync
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 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.
Re: [git-users] keeping two branches with partially different history in sync
Let me see if I understand this correctly. You want two things that differ from a common master by a few private commits, such as Master = A, B, C, D, I, J, K, L, M branch A = E, H, plus master branch B = F, G, plus master Did I understand that correctly? 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? On 2017-05-16, at 7:56 AM, matevz.lan...@borea.si wrote: > Hi, > > does anybody know how to keep 2 branches synced, each of them having 2 > specific/private commits, which must not be pushed to the second branch. They > have common history and common future. > > I want to have something like this: > > branch A: E--H--I--J--K--M >/ \ \ \/ > master: A--B--C--D \ \ \ / >\ \ \ \/ > branch B: F--G--I--J--K--L > > At any point in the future I would like to use regular "git merge A" and "git > merge B" to sync and B without loosing E,H and F,G respectively. > > This could be done by using orphaned branches A and B, but then I loose > common history which I also need to keep. > > Any ideas? > > thanks, > 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. --- 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.
[git-users] keeping two branches with partially different history in sync
Hi, does anybody know how to keep 2 branches synced, each of them having 2 specific/private commits, which must not be pushed to the second branch. They have common history and common future. I want to have something like this: branch A:E--H--I--J--K--M / \ \ \/ master: A--B--C--D \ \ \ / \ \ \ \/ branch B: F--G--I--J--K--L At any point in the future I would like to use regular "git merge A" and "git merge B" to sync and B without loosing E,H and F,G respectively. This could be done by using orphaned branches A and B, but then I loose common history which I also need to keep. Any ideas? thanks, 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.