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

On Sat, 13 Sep 2025 07:08:51 -0400
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:

> > > > 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.)    
> > 
> > I'm not totally up on the details, but I as I recall, the position of the
> > "VCS-selection-team" was that leaving the legally challenged stuff in the
> > repos, even if administratively maked out of bounds were not good enough.  
> 
> That makes sense.  The way hg implemented censoring (at least based on a
> quick read of some docs & code) is that the "bad" content is overwritten and
> a flag is added to the revlog to avoid checksum errors later on.  I'd have
> to experiment with it to see how censoring works in practice.
> 
> hg also has the concept called changeset evolution where it can keep track of
> old commit hash->new commit hash mapping as commits get rewritten.  This
> then informs the rest of hg about how to handle certain conflicts.  The
> intended usecase for this is multiple devs sharing a repo to iterate on some
> code without the super annoying conflicts that such sharing entails (anyone
> who's tried this with git knows how terrible the experience is without extra
> tooling/vcs that helps in any way).

What do you mean here? What a scenario could be to use same repo?

-- 
WBR, @nuclight