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

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.

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.

Jeff.