Andreas Ericsson wrote:
quoted text
>Stephen R. van den Berg wrote:
>>of time.  I need something that can be changed at will, then viewed with
>>gitk a second later.

quoted text
>A second later might be too much, but for the case where you need to
>add a patch in the middle (which I suspect is the most timeconsuming
>and tricky part at the moment), you might want to use a temporary
>branch checked out where you need to apply the patch, apply the patch
>and then rebase the rest of the history onto that new commit. Rebase
>is fairly quick (although not a one-second thing for 20k commits), so
>you'll get the time down quite a bit, I imagine.

Not really.
Rebase does two things:
a. Apply every patch/commit again, which takes too long for 20k commits.
b. Mess up carefully grafted parent/merge relationships.

Rebase is only suitable for short linear strands of commits.
The history I'm dealing with is neither short, nor linear.
-- 
Sincerely,
           Stephen R. van den Berg.

A truly wise man never plays leapfrog with a unicorn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html