-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/06/2018 06:42 AM, David Boddie wrote: > On Wed Sep 5 19:44:20 UTC 2018, Alessandro Rubini wrote: > >> Today I read some (most?) documents on the project's site, and I see >> that it's very similar, but on the flip side it looks like interactive >> rebases are not as easy as they are with git, and I really use them a >> lot (I write several features and test them all together, so I often >> squash my fixes in the original commit before pushing). > > Yes, I think there's a compromise between flexibility and simplicity. > Mercurial seems to be focused more on simplicity and ease of use, but that > might make certain tasks difficult to achieve depending on your workflow. > >> Also, I don't like much the data model (which is why, I think, changing >> the whole history is not as easy as with git). > > I think that is regarded as a feature in Mercurial. History rewriting may > be a useful feature in git but it could have limited use if your repositories > are already public. When Mercurial and git were evaluated at a former > employer the ability to rewrite the history was counted as an advantage for > git despite the problem that it would have been very difficult to justify > using it on the company's public repositories. > > Still, it's useful to have the option to do it, especially for private repos. > >> Thank you none the less, it was interesting reading. > > You're welcome. > > David
On the topic of history rewrite, I'd argue that allowing it on a private (read: development) repository provides better commits and less chance of losing work. It allows the developer to incrementally commit small, incomplete, possibly even wrong changes, then decide how they should be packaged and layered before attempting a merge. Without this capability, our programmers would tend to keep a massive chunk of unstaged changes locally, then submit the entire mess for review once it was working properly. History rewrite allows the developer to verify a multi-week, multi-layer, self-dependent modification and still be able to split it apart into logical, incremental chunks with relative ease. I can't imagine working without this feature. The lack of that feature on other source control systems might explain the relatively poor commit quality we have observed on those systems (or from people trained on those systems) over time -- their commits to be very large, doing way too much and touching too many files. Needles to say this causes a massive headache if/when the patch introduces a regression. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJbkWIJAAoJEK+E3vEXDOFbkyYH/2f5zIeAB5Quiqqjmy8sR4Le whtegBYPW0sYZikbN9xpC+hkzcA8RCSPMpUBspuOkDwlFgNrOvDmbHsz5gkAKNIW AuXoe5fctaV/88iVBOsXt0OtEP+N6/7F7BsvIvYvRbKk3eQK4uMbjwfyYWYX4hV8 vTQh1hVcUhAJwW2WEzOsKid0tN0/x05+GHADriZa8ksxoWmOg8XOxa3bzuhLyCM8 BtZC5aAxomI4pzPOXra2LkGUYcVHQQTqVtE4h/DleidqjX1LXEr7kgQwVpETtO3h /Yz/z1IjKlpAr1Bl8u5fioP+D0P+8ekRTlap/7EPTksHyjAlpLB51hPh4PN/odE= =5khl -----END PGP SIGNATURE----- _______________________________________________ Discussion mailing list Discussion@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/discussion This mailing list is covered by the FSFE's Code of Conduct. All participants are kindly asked to be excellent to each other: https://fsfe.org/about/codeofconduct
