[Python-Dev] Hg: inter-branch workflow

[Stephen J. Turnbull]

Ben Finney writes:

 > As a user of Bazaar primarily, that's addressing the problem in the
 > wrong place: why rewrite *my* history, which is useful to me as is, when
 > the other person is using Bazaar and so doesn't see revisions they don't
 > care about?

Speaking for myself, I rewrite my git history because it is *not*
useful to me as is.  Almost all of my git commits have a informational
half-life measured in hours once they're off tip, because I commit
with *every* save (I have an after-save-hook to do this), which I do
"early and often".  Effectively, I use git as an extension to XEmacs's
undo/redo mechanism.

I don't do this (yet, anyway) for hg or bzr because the projects where
I use those typically I only submit by patch or one-off commits rather
than long-ish branches.

 > Whether adding support in Mercurial or Git for similar
 > clean-presentation-by-default would obviate the need for rewriting
 > history, I can't tell.

It would probably decrease it, because many projects do have a
relatively centralized workflow where the bazaar approach of having a
distinguished mainline works well.  It is *highly* unlikely that it
would obviate it.  Aside from those of us who take a packrat approach
to committing as above, many git users (can't really speak for hg)
have a working style which involves lots of dynamic sharing "sideways"
with other users before pushing to the public mainline.  In these
workflows rebasing is a reasonable mechanism for "chunking" related
changes in the DAG, and helps to spread out the work of resolving
conflicts over time, while concentrating it in terms of the project's
module structure.