On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote: >On Mon, 21 Mar 2011 14:29:54 -0400 >Barry Warsaw <ba...@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
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
