Re: Git haas gone wild (Rust), freebsd-update

On Tue, 16 Sep 2025 07:22:05 -0400
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:

> On Sat, Sep 13, 2025 at 21:53:40 +0300, Vadim Goncharov wrote:
> > On Wed, 10 Sep 2025 09:40:52 -0400
> > Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:  
> ...
> > > I love hg, but git clearly won.  However, I think just about everyone
> > > conflates two things - the ui and the repo format.  So, I actually think
> > > that the git repo format won but there is a chance for the ui.  That is,
> > > it is possible to make hg operate directly on git repos.  I am *not*
> > > talking about things like hggit and similar projects that
> > > (semi-)transparently convert between hg and git repo formats.  I'm
> > > talking about true operation on the git object store and refs.  There is
> > > an *extremely* WIP extension in the hg repo called 'git' (see
> > > hgexit/git/*.py) that attempts to do this.  
> > 
> > The problem is that Git's UI in it's form arises exactly from the store
> > format architectural flaws - it tries to compensate for primitivism of
> > basic objects.  
> ...
> > Given the above, it's probably impossible to fix everything in git UI.  
> 
> The UI is awful because it is a fairly thin veneer over the underlying
> object storage.  But it doesn't have to be.  That's my point about people
> conflating the UI and repo format.  The repo format isn't perfect (e.g.,
> lack of rename tracking) but it is good enough.  The UI, on the other hand,
> is *not* good enough.

No, format is absolutely not "good enough". It is "just minimum to be workable
at all". For example, they don't have not only "inode-style" (I don't know
VCSes to use it yet, so it could be considered "advanced") but they can't even
just upgrade to SHA-256 from SHA-1 - these are incompatible (while e.g. Fossil
did it seamlessly) at all. As I've said earlier, commit has no information
about what branch it belongs to, it has direct consequence to having
"metropolitan railroad map" git logs if branches are merged, thus many, many
projects/companis choose to rebase/squash commits instead - that is, history
rewriting, which goes AGAINST the whole idea of Version Control (and yes, I've
many times found myself losing information due to this "squash to one" when
changing again and again in several tries to satisfy company's CI)

And Revase Considered Harmful (and history rewriting in general):
https://www.fossil-scm.org/home/doc/trunk/www/rebaseharm.md

And you can't solve this in UI without changing format - that's why it is not
even "good enough".

> For example, there are a some people that extoll the virtues of git's UI
> quirks like exposing the index to the user, but 99% of them then admit to
> have never used anything other than git.  When I ask them what they use this
> exposed index for, they always mention committing a subset of the changes.
> This can be done in other ways, for example some kind of interactive commit
> UI feature.  Note that other SCMs also have something like the index, but
> they keep it hidden from the user.

I agree, commiting a subset of changes (`git add -p .`) is the *only* real
usefullness of existense of index staging area.

> Anyway, I should stop before I outright start ranting :)

Why not! Ceterum censeo Git esse delendam!

-- 
WBR, @nuclight