Re: [git-users] Re: How to get a highly complex branch straight?
Am Dienstag, 2. Mai 2017 21:07:18 UTC+2 schrieb Philip Oakley: > > > I think you may have had expectations which were too high. Git can not do > magic. > All I'm asking for is to replay the already recorded history. Shouldn't require magic. > 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). [...] This assumes you want to see a progressive 'zipping > together' of the two development streams (picking the best of each). > Yes, this describes it perfectly, thank you. > The Mikado method [2] is one approach to avoiding a merge hell of trying > to do everything at once. > Here's another method I use for several years already, with great success: https://github.com/Traumflug/Teacup_Firmware/issues/81 Does not require to read a book, but does require a branch to be rebase-able. Markus -- 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] Re: How to get a highly complex branch straight?
Am Dienstag, 2. Mai 2017 19:30:33 UTC+2 schrieb Michael Gersten: > > > On 2017-05-02, at 10:22 AM, m...@jump-ing.de wrote: > > 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! > > > A better take-home message should be about how to prevent this from > happening in the future. > Preventing that is simple: don't merge. Or allow fast-forward merges, only. As soon as there are merges in a branch, one can no longer rebase it. What I don't understand, exactly, is "a branch with 4700 commits but zero > merges". I thought that merging was the goal here? > The goal is to do a simple rebase of this branch onto it's own. Like 'git rebase HEAD~1500'. As soon as this works, one can do interactive rebases, which allows to filter away the unwanted parts. And later rebasing wanted parts onto trunk (master), of course. I'm perfectly aware that some 80% of Git users merge often. Github offers pull requests as merges, only. Still merges get one into the mess described above if one wants to do something useful with the recorded history other than just staring at it. If you want to see a Git repo with zero merges for years and still a lot of collaborative development, see https://github.com/Traumflug/Teacup_Firmware Topic branches are rebased to latest trunk (branch 'experimental', in this case), then they get cherry-picked over, or trunk is rebased to the tip of the topic branch (which gives the same result either way). -- 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] Re: How to get a highly complex branch straight?
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.
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.
