to git or not to git
mkesper at fsfe.org
Mon Sep 10 10:01:29 UTC 2018
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
> (read: development) repository provides better commits and less
> of losing work. It allows the developer to incrementally commit
> incomplete, possibly even wrong changes, then decide how they should
> 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
> was working properly. History rewrite allows the developer to verify
> multi-week, multi-layer, self-dependent modification and still be
> to split it apart into logical, incremental chunks with relative
> 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
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)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 659 bytes
Desc: This is a digitally signed message part
More information about the Discussion