Am Samstag, 6. Mai 2017 01:38:13 UTC+2 schrieb Michael Gersten: > > > I admit that I did not follow this. So please clarify for me. >
It would certainly help if you could forget about this Mikado thing for a while. To make this forgetting easier, here are some statistics: a diff of 750.000 lines has perhaps 5% problematic areas. That's 37500 lines. Let's guess every problematic area has 20 lines of code on average. That means you have to try, note and roll back 1875 times. 10 minutes for each try and 18750 minutes or 312 hours or ~2 months have passed. Still not a single area fixed, much less all these areas put together. Instead, let's look at what rebasing does. Git documentation mentions such procedures as "working with topic branches" A---B---C---D---E---......---ZX---ZY---ZZ master \ 1---2---3---......---4378---4379 subsystem The usual rebase would be to do a git checkout subsystem git rebase master With extremely large branches, this won't work. You'd get all the conflicts you'd get with a merge, too. Accordingly, let's try in small steps: git checkout subsystem git rebase C You see the advantage? - Code changes to branch subsystem are small. Only what commit C changes on the other branch. - Code changes applying flawlessly get resolved by Git automatically. No need to start the code editor. - As changes are small, conflicts appearing are small, too. Accordingly they're easy to solve. - Because commit C is (hopefully) focussed on one topic, testing is much easier. One has to test just the changed code section. - If conflicts appear during the rebase, one can look at what each of the branches changed at the conflict point to find a good resolution. - If things end up in a mess, rolling back is a simple as 'git rebase --abort'. - If the rebase succeeds, but code still breaks, one knows pretty exactly where to search for the bug: these changes in commit C. - In case one still fears to mess up, making a branch copy as backup is trivial. - After each rebase step, code compiles and works. - Once such a rebase step is done, problems solved never re-appear. No need to take notes, no need to remember something, no need to solve a problem twice. With such a small rebase done, the repo looks like this, the dangling end of branch 'master' is one commit shorter: A---B---C---D---E---......---ZX---ZY---ZZ master \ 1---2---3---......---4378---4379 subsystem That's about as quick and easy as one can make such a task. With one rebase done, next ones follow: git rebase D git rebase E ... ... Up until one can do a final 'git rebase master'. The benefit of Mikado's "always rollback" approach is that you can continue > making fixes/updates/improvements. Always rolling back means you always start from scratch. "Taking a note" is no solution. It's just a note. > NB: Do not assume that "you don't need to document". Large projects, > multiple people, long time (enough to forget something), all add up to > "Document, document, document". > I conflicts appear during a step-rebase, one can write notes right into the commit message. -- 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.