to git or not to git

[Michael Kesper]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fsfe.org/pipermail/discussion/attachments/20180910/5621917f/attachment.sig>