Re: cvs better than git?

[a l3x <w4m4ck%gmail.com@localhost>]

On Mon, Jun 22, 2020 at 7:51 AM Andreas Krey <a.krey%gmx.de@localhost> wrote:
>
> On Sun, 21 Jun 2020 17:53:49 +0000, Aaron B. wrote:
> ...
> > ...if it's not final, why is it called a "commit"?
>
> Commits in git are immutable - given the commit id you can even verify its
> contents. But since they start their existence in your local repository
> it's much easier to just drop them - undo the commit, and commit a
> different set of changes instead.
>
> If git didn't offer this on itself (git commit --amend), you could just
> tar your local repo beforehand, and restore it if you messed up a commit.
>
> So, commits are final in that you cannot change them, but they can be
> forgotten, so you can fix mistakes after an accidental commit.

git follows a snapshot like approach to version control. but this view of
history bites you as can be seen in "merge commits". requiring "rebasing"
things and actually "rewriting history". this is what i dislike about the design
of git. it is just a hash based object store. maybe that's the reason
why the cli is
cluttered with lots of details. merge commits call for trouble and for
rebase, this is why i consider the design of git as VCS broken at best.

another approach e.g. is using a partial order of patches as utilized
by darcs, or
pijul. an example on the difference of darcs vs git can be found there:

https://darcsbook.acmelabs.space/chapter01.html#why-darcs

unfortunately you can run into computational complexity issues which are
kind of relaxed in dacrcs v2 if i'm correct.

i wish they had written darcs in idiomatic straight line c/c++. haskell, and in
case of pijul rust are kind of show stoppers for me.

i routinely run into issues with git when using it in the advocated
"decentralized"
manner. but this is probably my fault.

best, al3x.