to git or not to git

[Timothy Pearson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/06/2018 06:42 AM, David Boddie wrote:
> On Wed Sep 5 19:44:20 UTC 2018, Alessandro Rubini wrote:
> 
>> Today I read some (most?) documents on the project's site, and I see
>> that it's very similar, but on the flip side it looks like interactive
>> rebases are not as easy as they are with git, and I really use them a
>> lot (I write several features and test them all together, so I often
>> squash my fixes in the original commit before pushing).
> 
> Yes, I think there's a compromise between flexibility and simplicity.
> Mercurial seems to be focused more on simplicity and ease of use, but that
> might make certain tasks difficult to achieve depending on your workflow.
> 
>> Also, I don't like much the data model (which is why, I think, changing
>> the whole history is not as easy as with git).
> 
> I think that is regarded as a feature in Mercurial. History rewriting may
> be a useful feature in git but it could have limited use if your repositories
> are already public. When Mercurial and git were evaluated at a former
> employer the ability to rewrite the history was counted as an advantage for
> git despite the problem that it would have been very difficult to justify
> using it on the company's public repositories.
> 
> Still, it's useful to have the option to do it, especially for private repos.
> 
>> Thank you none the less, it was interesting reading.
> 
> You're welcome.
> 
> David

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

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

iQEcBAEBCAAGBQJbkWIJAAoJEK+E3vEXDOFbkyYH/2f5zIeAB5Quiqqjmy8sR4Le
whtegBYPW0sYZikbN9xpC+hkzcA8RCSPMpUBspuOkDwlFgNrOvDmbHsz5gkAKNIW
AuXoe5fctaV/88iVBOsXt0OtEP+N6/7F7BsvIvYvRbKk3eQK4uMbjwfyYWYX4hV8
vTQh1hVcUhAJwW2WEzOsKid0tN0/x05+GHADriZa8ksxoWmOg8XOxa3bzuhLyCM8
BtZC5aAxomI4pzPOXra2LkGUYcVHQQTqVtE4h/DleidqjX1LXEr7kgQwVpETtO3h
/Yz/z1IjKlpAr1Bl8u5fioP+D0P+8ekRTlap/7EPTksHyjAlpLB51hPh4PN/odE=
=5khl
-----END PGP SIGNATURE-----