Date: Sat, 13 Sep 2025 22:10:35 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: Josef 'Jeff' Sipek <jeffpc@josefsipek.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Git haas gone wild (Rust), freebsd-update Message-ID: <20250913221035.585d8a4b@nuclight.lan> In-Reply-To: <aMVQww-s8SrIcIhM@satis> References: <00202803-6a1a-44ca-b110-9f1404d2c9bc@FreeBSD.org> <CAN0SSYwGC1G8s5Ygb6rKqX2yPSoCCeJAyFk0gscBW0b94BwWRA@mail.gmail.com> <39D21672-603B-42A6-8820-F274FCC1191D@nxg.name> <20250909131346.1e1011ea@nuclight.lan> <aMAWErNE7apNtZGo@satis> <202509091901.589J1RGX017686@critter.freebsd.dk> <aMF_5I8gm4KDXG9V@satis> <202509130746.58D7kNHN004849@critter.freebsd.dk> <aMVQww-s8SrIcIhM@satis>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250913221035.585d8a4b>