On Tue, 2009-09-15 at 05:12 -0700, joel@... wrote:
> > You can do most of that with the bzr-rebase plugin, but I'd
> > against it. Honestly, the only reason I've seen to reorder commits
> > to lie and say you never make mistakes, or to clean up a
> > to make it look better. I don't think either of those are good
> > to "change history." I'm kinda a historian on that point, it seems
> > 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.