Re: is rebase the same as merging every commit?

Thanks for the explanation.

However, when considering an SCM perspective, I don't understand why I have to make a tradeoff between personal reproducibility (which I get from the original changes), and upstream readability (which the community gets from my rebase).

I could get both of these if the rebase kept both the old and new.

Is there some reason that losing personal reproducability, and personal/local tracking back to those changes of A-B-C is necessary as part of the process?

Further, the rebase machinery seems like it would be great for operations that are even more 'dangerous', where I would really really want the history of the transitions in case I realized a problem later.

Consider this set of commits on a personal branch

0 - feature a 1 - feature b 2 - bugfix a 3 - feature c / d 4 - bugfix b 5 - bugfix a2

like the three steps are Reorder, combine, rebase. (In a more complicated situation, i'd want to split a commit into pieces)

(1'') 0' - feature A 1' - bugfix a 2' - bugfix a2 (2'') 3' - feature b 4' - bugfix b (3'') 5' - feature c (split) (4'') 6' - feature d (split)

Frankly, I'm super impressed, because I can imagine how I might do this in git. I'm guessing some of you are already doing this. But how do you do it? Can you rebase a patch back into it's own history? (such as bugfix a from 2, to 1')

I want to mess around and try this stuff out, but I'm scared of doing bad things to the tree and them being unrecoverable because rebase tosses the old stuff. I don't understand why I have to lose my original work and/or the connection to my original work, in order to reorder/combine/split for public consumption. What is the argument for that? (other than the fact that the current dag link propagation model would force others to get these changes if they remained connected together. Something easily remidied by out of band metadata, or different link types)