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