Hi all, Am Donnerstag, den 06.09.2018, 12:21 -0500 schrieb Timothy Pearson: > 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.
I much prefer a proper review system like Gerrit for that. You submit code which will be broken (for sure), but you have the chance of checking it manually and automatically _before_ committing to the repository. Also no code will be lost if your dev machine dies in a week long develop/rewrite cycle (did you consider that possibility?). Additionally you can use it to keep your repo in always-fast-forward state with linear, easy to follow history. Better explanation than I can do: https://sandofsky.com/blog/git-workflow.html My three pluses: + Review/Tests: Everything not tested will break, so don't let untested code into the repo at all + Small changes instead of one big monster commit + Linearity (when using rebase) Best wishes Michael
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
