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

On Sat, Sep 13, 2025 at 22:10:35 +0300, Vadim Goncharov wrote:
> 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?

Sorry, I should have been clearer...

Suppose there is a repo on a server and two developers clone it.  Then, one
dev creates a series of commits, and pushes them as drafts to the server.
The other dev pulls the series from the server, modifies one of the commits
in the middle of the series, and pushes the result back to the server.
(*Not* a force-push because the server knows that the old and new commits
are related!)  Meanwhile, the first dev continued tweaking the series.
Sooner or later, the first dev will want to combine his modifications with
what the second dev pushed.

(The "same repo" I referred to in my previous email is the server repo in
this example.)

With git, this kind of rewriting results in force-pushes and awful headaches
and/or out-of-band mutual exclusion/coordination that the devs have to do.
With hg's changeset evolution, hg knows how each commit evolved (commit abc
turned into commit def for reason ghi) and it can use this second order DAG
to almost always do the right thing.  In handful of instances when it can't
resolve it automatically, it still gives the user the second-order DAG
information about how the situation happened.  (Compared to git's "here are
two piles of commits, enjoy" approach.)


Here's an example output from hg showing a portion of this second-order DAG for
a commit I worked on for an unrelated project (slightly trimmed for brevity).  

$ hg obslog -r e6dd6779c419
o  e6dd6779c419 (8571) Document HLQ0 file format
|    rebased(parent) from 5943a3e1932e using histedit by Josef 'Jeff' Sipek <jeffpc@josefsipek.net> (Sat May 10 11:21:02 2025 -0400)
|
x  5943a3e1932e (8570) Document HLQ0 file format
|    rewritten(description, content) from 6fa0a1a05747 using amend by Josef 'Jeff' Sipek <jeffpc@josefsipek.net> (Sat May 10 11:19:42 2025 -0400)
|
x  6fa0a1a05747 (8569) WIP: Document HLQ0 file format
|    rebased(parent) from 32d556ef2864 using rebase by Josef 'Jeff' Sipek <jeffpc@josefsipek.net> (Sat May 10 11:17:38 2025 -0400)
...
x  764a6f9cc777 (7549) WIP: Document HLQ0 file format
|    split(description, date, parent, content) from fabfad0ef96a using split by Josef 'Jeff' Sipek <jeffpc@josefsipek.net> (Mon Aug 05 20:20:50 2024 -0400)
|
x  fabfad0ef96a
|    amended(content) from 607546bdae0f using amend by Josef 'Jeff' Sipek <jeffpc@josefsipek.net> (Mon Aug 05 20:19:05 2024 -0400)
|
x  607546bdae0f

Jeff.