Re: Slightly off topic, question about git

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

On 2022-06-06 14:33, Mouse wrote:
> > 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.
>
> That's not a fault of git; that's a fault of how some people use git.

Well, you could argue that it's a fault in git that it allows it.

If there is a way, then some people will use it that way.

> > 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.
>
> And git can be used that way.  No VCS is ever truly never-change,
> unless you use write-once media to store it, and even then it is always
> vulnerable to reconstructing a new repo from the ground up based on the
> old repo.

Sure. You can change history in CVS as well. But you'll have to go in 
there and much with the data that is beind. It's not like the UI itself 
allows you to work that way. And I've not seen anything similar in a 
whole bunch of other VCSs I've worked with either. But I've generally 
not worked on distributed once before.
And I sortof can see why people want to go that way, since with 
distributed VCSs, it becomes much harder to have a linear history. But 
they still want to kindof/sortof fake it.

> > 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.
>
> Not really; history doesn't _have_ to be rewritten.  That's what merge
> commits are for.  People just choose to rebase work instead of merging.
> (Personally, I think that's a mistake, for various reasons, but, as you
> point not, not everyone agrees.)

It sortof have to. Since if you've done various work, and others have 
done various work on the same files, and both have done commits, it 
might not be possible to merge as is. And so you'll have to rewrite 
parts that you already committed in order to get things back to a 
coherent state.

This is a nasty problem when you have separate VCSs. Well, it becomes 
nasty because somewhere in the end, you still have a master VCS, which 
holds the source of truth. Distributed VCSs are not truly distributed. 
There is still just one master. It's just about how you work in relation 
to it. I can see some advantages, but I'm still not sure if they 
outweigh the disadvantages that I feel. But that is of course very 
subjective.

  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