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 [email protected].
For more options, visit https://groups.google.com/d/optout.
