On 09/06/2018 02:46 PM, David Boddie wrote: > On Thursday 6. September 2018 12.21.17 Timothy Pearson wrote: > >> 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. > > But are they sharing the changes they commit before rewriting the history > and sharing it with colleagues?
No, and I should have pointed that out. When you start sharing, all bets are off and history should not be rewritten, however at the same time you're not likely to be sharing broken / nonfunctional code that's still in the middle of a rewrite. At the very least, it would be expected that you clean up your own mess a bit before trying to engage a colleague for assistance, to avoid wasting time all around, and even then it would be in some kind of WIP branch that would be deleted later on. >> 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. > > I think it depends more on the workflow more than the features of the > revision control system. Of course, those people used to non-distributed > systems may be in the habit of batching their commits for several unrelated > issues because they are used to a centralised model where committing a change > involves sharing it with everyone else. > > I think you could do something similar to git with Mercurial but it wouldn't > be exactly the same. As long as the general class of functionality is present, that's fine. No ability to stage and rework a commit stack though is going to push people more toward the monolithic / batched commit mode from what I've seen. > David > _______________________________________________ > 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 -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com _______________________________________________ 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