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

From: Josef 'Jeff' Sipek <jeffpc_at_josefsipek.net>
Date: Tue, 16 Sep 2025 11:22:05 UTC
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.

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.

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

Jeff.