to git or not to git

[David Boddie]

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?

> 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.

David