-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2011 04:33 PM, Barry Warsaw wrote: > 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. Having bisect able to use the intermediate changesets (as an option) could even make it easier to pinpoint the correct fix for a bug (assuming people don't routinely make local changes of complete "guts-on-the-table" messes). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2HuFUACgkQ+gerLs4ltQ6+bACeLETaWB34XZwvJIPYkP3mddrU JRoAoKCNTnkjFlQe8xXNJdyYUDHoSiFs =ksyC -----END PGP SIGNATURE-----
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4