to git or not to git

Timothy Pearson tpearson at raptorengineering.com
Thu Sep 6 20:40:49 UTC 2018


On 09/06/2018 02:46 PM, David Boddie wrote:
> 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?

No, and I should have pointed that out.  When you start sharing, all
bets are off and history should not be rewritten, however at the same
time you're not likely to be sharing broken / nonfunctional code that's
still in the middle of a rewrite.  At the very least, it would be
expected that you clean up your own mess a bit before trying to engage a
colleague for assistance, to avoid wasting time all around, and even
then it would be in some kind of WIP branch that would be deleted later on.

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

As long as the general class of functionality is present, that's fine.
No ability to stage and rework a commit stack though is going to push
people more toward the monolithic / batched commit mode from what I've seen.

> David
> _______________________________________________
> Discussion mailing list
> Discussion at 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


-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com



More information about the Discussion mailing list