On Tue, 2009-09-15 at 05:12 -0700, joel@...1709... wrote:

...

You can do most of that with the bzr-rebase plugin, but I'd

recommend

...

against it. Honestly, the only reason I've seen to reorder commits

is

...

to lie and say you never make mistakes, or to clean up a

visualization

...

to make it look better. I don't think either of those are good

reasons

...

to "change history." I'm kinda a historian on that point, it seems

like

...

history is history -- leave it alone :)

Tidying history is helpful. It enables people to go off on experimental tangent branches knowing that they can bring order out of chaos when they're ready. It also means that we don't have to have patches merged that break inkscape. It's good to keep a clean history, and you can use bisect to find problems in that case.

Uhm, I don't see how changing the number of revisions would effect how the patch applies in any case. Neither would which changing which revision the branch started on.

I assure you that I go on experimental tangent branches regularly, that's simply the kind of person that I am. The histories there are still important even though you'd never see them unless you started really delving into the revision history to see each commit. When I merge it into main is when I write a more useful message about what really changed, as most people only look at the history of trunk anyway.

--Ted