Hi @mah, I think you may have had expectations which were too high. Git can not do magic.
The problem of product branches that divereged a long while ago is not new. Even when the two product teams claim that their respective code bases have converged they are rarely anywhere near each other for merging (automated computer merges). Usually it is just the user visible portions that look similar - underneath there are vast differences[0]. The learning message should be that one should "merge early, merge often and merge small chunks" (and have automated test to check it all still works;-). The problem is usually that the lesson isn't headed at the beginning and the technical debt is allowed to build up.[1] The other problem here is one of terminology. We usually do not have consistent terms to describe the problem well. I think your project had two lines of development which forked and then ran independently. The two forks each had their own branch-merge processes in place (so each line has merges on it, but no cross merges between the two forks). .At tha point you would need to do a bit a forensics to identify in each of the development lines the useful refernce points (releases/tags/etc) that can be used for comparison. By limiting the number of commits that will be compared you will have less conflicts to resolve (solve once and move on). This assumes you want to see a progressive 'zipping together' of the two development streams (picking the best of each). The Mikado method [2] is one approach to avoiding a merge hell of trying to do everything at once. However if you have found a method that works for you (and others on the other line of development) then that is all to the good. It's never easy rationalising disparate code bases. Summary ======= "merge early, merge often and merge small chunks". -- Philip [0] white space; blank lines; bracket placement; variable names; function names; loop control; ..; features implemented; OSes supported;.. on it goes. [1] Youth is wasted on the young, and wisdom wasted on the old; Or something like that. Hindsight is wonderful. [2] Mikado method, https://www.amazon.co.uk/d/cka/Mikado-Method-Ola-Ellnestam/1617291218 https://mikadomethod.wordpress.com/ ----- Original Message ----- From: Michael To: git-users@googlegroups.com Sent: Tuesday, May 02, 2017 6:30 PM Subject: Re: [git-users] Re: How to get a highly complex branch straight? On 2017-05-02, at 10:22 AM, m...@jump-ing.de wrote: As nobody knew an answer, so I started trying rebase strategies (-s, -X options), one by one. Using 'git rebase -s recursive -X ours ...' was the only one which did something useful for this self-rebase and also worked with a mangeable set of conflicts (only ones including a file deletion), so I got away with resolving some 30 conflicts with 'git rm ...'. Now I have a branch with 4700 commits on it, but zero merges. Diff melted down to 3800 lines. That's something I can work with. Go home message: merges are evil! Merges should not be evil. Something really odd was going on here. A better take-home message should be about how to prevent this from happening in the future. What I don't understand, exactly, is "a branch with 4700 commits but zero merges". I thought that merging was the goal here? -- 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. -- 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.
