[Python-Dev] Hg: inter-branch workflow

[Daniel Stutzbach]

On Sun, Mar 20, 2011 at 9:39 AM, Georg Brandl <g.brandl at gmx.net> wrote:

> Now, "hg pull --rebase" prevents that by "re-basing" the A-B history
> line onto the latest remote head.  After rebasing, the history looks
> like this:
>
> ... --- X --- C --- D --- E --- A' --- B'
>

Rebasing also allows you to collapse the commits, so you can make the tree
look like this:

... --- X --- C --- D --- E --- AB'

Collapsing commits is useful for keeping the repository clean.  For example,
I make commit A and send it for review.  Someone points out some flaws and I
make commit B.  I don't want the flawed version checked in to the main
repository, so I collapse the commits into one commit AB'.

Keeping the repository clean makes it easier to use a bisection search to
hunt down the introduction of a bug.  If  every developer's intermediate
commits make it into the main repository, it's hard to go back to an older
revision to test something, because many of the older revisions will be
broken in some way.

In reality
> it works fine if you know the limits: rebasing really only should be
> applied if the changesets are not already known somewhere else,
> only in the local repo you're working with.


The changesets must only be in the local repo *and* they must not have been
merged into another branch yet.

On Sun, Mar 20, 2011 at 9:21 AM, Guido van Rossum <guido at python.org> wrote:

> Why does everyone want it and hate it at the same time?
>

People love it because it's a very powerful tool.  People hate it because it
allows you to shoot yourself in the foot.

-- 
Daniel Stutzbach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/c7bbf427/attachment.html>