Re: cvs better than git?

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

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.

Usually, you configure your central, 'blessed', repo so that you cannot
drop commits there, and only add new ones, but this is a choice you make,
and not something built into git itself.

Example: Our integrators take pull requests (that have run their tests
individually, of cource), and merge a set of those locally, without
making the result visible to the dev population yet. Run tests on the
result, and, since feature interaction is a thing, sometimes these tests
break. In that case they drop the merge commits, and try with a different
set of pull requests, and the original set gets lost.

You can do this model in svn if you create a temporary branch for these
integrations each time, and, after a successful build, merge that into
trunk. Likewise, you *can* 'amend' a commit in svn by creating a new
branch from the revision before, commit on that, delete the old branch
and move the new branch to the old name. But it's so unwieldy that nobody
bothers, the mergeinfo properties may quite probably bite you, and there
is no usable way to visualize the result anyway, even with 'git svn'.
And of course, in svn these antics stay in the revision history.
Unless you manipulate the server.

- Andreas

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