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.

Reply via email to