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

On Wed, 10 Sep 2025 09:40:52 -0400
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:

> On Tue, Sep 09, 2025 at 19:01:27 +0000, Poul-Henning Kamp wrote:
> > --------
> > Josef 'Jeff' Sipek writes:
> >   
> > > > > > Or switch to
> > > > > > Mercurial, https://www.mercurial-scm.org/ and declare git as obsolete    
> > > > > 
> > > > > I think that's an excellent idea, for both technical and social
> > > > > reasons!  
> > 
> > I seem to remember that we had a huge VCS shootout back in previous times
> > and that hg basically lost because they had no way to truly "obliterate"
> > a commit, if for instance laywers waved a credible cease&desist letter.  
> 
> Taking a quick look, it looks like the revlog format hg uses has the correct
> bits to allow for censoring of parts of history.  So, it should work with
> minimal fuss.  (I've never used this feature, so maybe there is more to it.)
>  
> 
> > As I recall that (hard!) requirement was caused by the Tetris trademark
> > thing.
> > 
> > Is this still a concern for the project ?
> > 
> > How does the various VCS's handle that, or have we decided on
> > roll-back-and-recommit as mitigation ?  
> 
> I can't answer any of these questions since I can't speak for the project.
> From a usability perspective, rewriting history (rollback & recommit) is
> rather awful (especially in git).
> 
> 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.
Git could be compared to FAT16 in filesystems' area - name directly refers to
contents, no "inode", so there `blame` and, more importantly, rename problems:
they (deliberately!) do not record this info, trying to guess, which is
especially painful in repos like /usr/ports with thousands of same-named files.
While I've seen no DVCS with a true "inode", at least Fossil has a field
"renamed from" to help alleviate the problem.

Another stupidity of Git's format is lack of any attributes - not only
"extended" such as SVN props, but even basic, like "which branch does this
commit belong to" - in fact there are no real branches, just pointers to their
heads, leading to all sort of problems, from minor like "detached HEAD" to
most harmful - "rebase"/"squash" history rewriting (which contradicts with
the whole idea of VCS). See, if you regularly merge branches one to other,
soon your history graph looks like railroad station - to mediate this, the
often policy is to squash whole branch to single commit to "master" ("dev",
whatever). This is because there is just no info saved in the store - so
your UI can't do anything useful here (unless you try hacks like teaching
it heuristics of particular project's policy *and* enforce this policy).
In contrast, Fossil has tags on every commit, one which is branch name (btw,
allowed to be non-unique, as it is possible to "close" branches) - now, in UI
you can show neatly just one your branch without web of all other branches:
just little arrows incoming or outgoing from whatever is selected to be shown
"trunk"-style. You now don't have to rebase or squash losing history - just
merge and show what is relevant (Fossil's Web UI is much more comfortable than
e.g. GitHub one).

> This extension is extremely unfinished and has some scalability issues.  I
> tried to improve them a while back (so I could use in on the freebsd repo),
> but the storage layer in mercurial core is not quite fully abstracted and so
> it makes some assumptions about what is cheap and what is expensive.
> Assumptions that are true about revlogs but not about git
> blobs/trees/commits.  The hg devs are certainly interested in both making
> the hg storage core API-ified and the git extension seeing more development.
> (As a side note, the rust code they are writing is forcing some of the
> necessary API-ification that makes the git extension more feasible.)
> 
> So, if you are good with python and dislike git's ui, feel free to help hg
> become an alternate ui.

Given the above, it's probably impossible to fix everything in git UI.

-- 
WBR, @nuclight