Re: Slightly off topic, question about git

[Johnny Billquist <bqt%softjar.se@localhost>]

On 2022-06-06 11:32, Greg Troxel wrote:
> David Brownlee <abs%absd.org@localhost> writes:
>
> > I suspect most of this also works with s/git/hg/ assuming NetBSD
> > switches to a mercurial repo
>
> Indeed, all of this is not really about git.  Systems in the class of
> "distributed VCS" have two important properties:
>
>    commits are atomic across the repo, not per file

True of most any VCS, distributed or not. It's rather CVS that is the 
odd man out here. But it's sortof a bit loose (or weird) in distributed 
VCSs, since you might do that to your local repo, but then it becomes 
"diluted" when it gets applied to another (upstream) repo.

>    anyone can prepare commits, whether or not they are authorized to
>    apply them to the repo.  an authorized person can apply someone else's
>    commit.

Anyone can "prepare" a commit on any kind of VCS. It's the actual commit 
that is always the gate.
The difference might more be in how you pass a commit over to someone 
else to apply. With CVS, I usually create a diff, and send that to 
someone who have the rights to apply it. Works just fine. (Since I don't 
have any commit rights on NetBSD for example.)

> These more or less lead to "local copy of the repo".  And there are web
> tools for people who just want to look at something occasionally.    But
> I find that it's not that big, that right now I have 3 copies (8, 9,
> current), and that it's nice to be able to do things offline (browse,
> diff, commit).

Local copy is required with git, since everyone actually have their own 
VCS. And then you have some upstream VCS which you work 2-way with, in 
relation to your own VCS.

Pros and cons, as always.

> CVS is really just RCS with
>    organization into groups of files
>    ability to operate over ssh (rsh originally :-)
> That was really great in 1994; I remember what a big advance it was
> (seriously).

True.

I've recently come to realize a thing with git I really abhor. It has a 
very loose view on history immutability. I've seen branches, which 
claims to come from some point, where the branch is way older than the 
revision it claims to have been branched off.
Which obviously is impossible. But history rewriting seems to be a 
favorite pastime of git users.

For me, one of the really big points of VCS is that history is never 
changed. I can go back and see what was done, where, to what.

Since git actually is multiple, independent VCSs, what happens on one 
don't necessarily at all come across to another, and in the process of 
aligning them, history have to be rewritten to even get close to make 
some kind of sense.

I'm not at all convinced this is a good system. But that's just me. :-)

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol