Advocacy vs. git

[Bill Barry]

Theodore Tso wrote:
> How useful you find rebase really depends on where you find yourself
> on the continuum between:
>
>    *) What should be stored in the source code repository is the
>       "perfect patch" or "perfect patchset" which implements a
>       particular feature or bug fix.  Typos, bug fixes, merges to
>       track changes in the upstream should be omitted since they dirty
>       up the repository and make it harder to understand six months
>       later --- especially if there is a desire to cherry-pick the
>       patch for backports.
>
>    *) Everything that should be stored in the source code repository,
>       development warts and all, and it should be stored forever,
>       since it reflects the development history.

 From a viewpoint very close to the latter (we have a habit of 
committing just about after every compile and successful test run):

We all push to a central location and we don't like having multiple 
heads on that central repo. So we have the following scenarios:

1.
$ hg ci
$ hg push
...
(push succeeded, we are done)

2.
$ hg ci
$ hg push
abort: push would create multiple heads (or something like that)
$ hg pull
$ hg merge
(changes are completely disjoint)
$ hg ci -m automerge
$ hg push
(potentially repeating)

3.
$ hg ci
$ hg push
abort: push would create multiple heads (or something like that)
$ hg pull
$ hg merge
(changes are not disjoint, manual merges may be needed)
$ hg ci -m "merged blah by blah blah ..."
$ hg push
(potentially repeating)

4.
$ hg ci
$ hg push
abort: push would create multiple heads (or something like that)
$ hg pull --rebase
$ hg push


usually I only do #4 when I already know that there is a disjoint 
changeset out there. Basically the only reason to do it is just to make 
the graph more pretty and to get rid of a changeset.