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

On Mon, 15 Sep 2025 21:12:25 -0400
Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:

> 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

What is "modifies one of the commits"? Amend due to mistake? If not, then why?

> 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.

Sounds like these developers for some reason did not used branches, while they
had to. That is not a normal workflow, then.

> 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

I did not work with hg so don't know - are those comments like "rebase" just
comments, or it is recorded more usably in artifact format and actually used?

-- 
WBR, @nuclight