Andreas Ericsson wrote:
>Stephen R. van den Berg wrote:
>>of time. I need something that can be changed at will, then viewed with
>>gitk a second later.
>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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
