[Python-Dev] Hg: inter-branch workflow

[Barry Warsaw]

On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:

>On Mon, 21 Mar 2011 14:29:54 -0400
>Barry Warsaw <barry at python.org> wrote:
>> >
>> >I don't think many hg users advocate rebase, really. AFAICT the
>> >Mercurial developers themselves don't seem to use it (they do use mq,
>> >OTOH).
>> 
>> I guess that begs the question then. ;)  
>> 
>> What harm would there be in relaxing the SHOULD in this paragraph to MAY?
>> 
>> "You should collapse changesets of a single feature or bugfix before pushing
>> the result to the main repository.
>
>Because it's really SHOULD.
>Apparently some people misunderstand this statement. "collapse
>changesets of a single feature or bugfix" doesn't mean you must avoid
>merges. If that's the impression it gives then the wording SHOULD (;-))
>be changed.
>
>The paragraph is aimed at the temptation people may have to commit many
>changesets for a single feature/bugfix and push them all even though
>some of them don't leave the source tree in a stable state. What it
>says is that we don't want work-in-progress changesets in the public
>history.
>
>Again, a better wording is welcome.

I guess it depends on what "work-in-progress changesets" means. ;)

If I'm working on a new feature, I am going to make lots of local commits, any
one of which may not actually be stable.  However, when my work on that
feature branch completes, I will have a fully functional, stable branch that's
ready to merge into the default branch.

As Ben described clearly, with Bazaar, I'd just merge my work-in-progress
branch to default and be done.  Tools such as bisect and log would ignore all
my intermediate changes by default, although you *can* drill down into them if
you want.  But I take it that with our Mercurial workflow, we'd rather all
those intermediate commits in my local branch were manually collapsed before I
merge to default.

My discomfort with this is not just that it changes history, but that it
throws away valuable information.  Sure, you're not going to care if I fixed a
typo in NEWS, but you might indeed care that I've addressed the issues you
raised in your first, second, and third reviews.  Each of those would be
represented by a changeset in my local line of development, and by a side
branch in the mainline DAG once my merge is completed.  You might want to dig
into that sideline to see if indeed I addressed the issues in your second
review of my code.  If we have to manually collapse changesets at feature
branch merge time, you can't do that.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110321/8d05d977/attachment.pgp>