Re: cvs better than git?

[Andreas Krey <a.krey%gmx.de@localhost>]

On Mon, 22 Jun 2020 09:37:30 +0000, a l3x wrote:
...
> git follows a snapshot like approach to version control. but this view of
> history bites you as can be seen in "merge commits".

Excuse me? Is there any VCS that doesn't record merges?

> requiring "rebasing" things and actually "rewriting history".

None of these are required. You *can* modify history;
you are not required to do that. And the farther a commit
has propagated the harder it gets to 'revoke' it.

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

Those are mostly unrelated. git has an unusual local working model
('staging area' aka 'index'), plus it doesn't try to shield you
from its data model.

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

So now, darcs' model with patch reordering etc. is *exactly*
what 'git rebase' does. You rebase your local branch onto
the incoming stuff; git treats the commits as patchsets,
and figures out which ones were already applied and
which ones need to remain.

If you do 'git pull --rebase' from your colleague's branches,
you *have* a darcs in C (to some extent).

git conceptually stores commits as a full tree, plus a reference
to the parent commit (or commits, in case of merges). But since
the parent commit and hence tree is known, you can just as well
consider a commit to be a patch set, and there are some commands
that do just that.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800