[Python-Dev] Hg: inter-branch workflow

[David Cournapeau]

On Tue, Mar 22, 2011 at 1:20 AM, Barry Warsaw <barry at python.org> wrote:
> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
>
>>On 20.03.2011 16:21, Guido van Rossum wrote:
>>> What is "rebase"? Why does everyone want it and hate it at the same time?
>>
>>Basically, rebase is a way to avoid having pointless merge commits on the
>>same branch.
>
> There's something I don't understand about rebase.  It seems like most git and
> hg users I hear from advocate rebase, while (ISTM) few Bazaar users do.

I cannot talk for the communities in general, but that's mostly
cultural from what I have seen, although the tools reflect the
cultural aspect (like fast forward being the default for merge in
git). Hg up to recently did not have rebase at all, so it is less
ingrained it seems.

The reason why I like using rebase in general is because it fits the
way I like thinking about git: as a patch management system when I
work alone on a branch. I don't think private history is that useful
in general, but that depends on the projects of course. Another aspect
is that some people learnt git first through git-svn, where rebase is
the defacto way of working.

The issue of committing something that does not correspond to a tested
working tree is moot IMO: the only way to do it correctly and reliably
is to have some kind of gateway to actually test the commit before
adding it for good to the reference repo. In my experience, the most
common way to commit a broken working tree is to forget adding a new
file or removing an old file (e.g. the code depends on some old file
which has been removed while the old .pyc is still there), and none of
svn/bzr/hg/git prevents that.

David