groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Groff History in Git. (Was: groff in git)


From: G. Branden Robinson
Subject: Re: Groff History in Git. (Was: groff in git)
Date: Mon, 12 Dec 2022 09:06:03 -0600

Hi Dave,

At 2022-12-12T08:38:45-0600, Dave Kemper wrote:
> On 12/12/22, G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
> > At 2022-12-12T09:06:22+0000, Ralph Corderoy wrote:
> >> A Git commit ID is effectively a hash of its ancestry so that
> >> history can't be changed in this case without the unwanted ripple.
> >
> > I concur with Ralph's analysis.
> 
> I feared this might be true but hoped to be wrong, or at least that
> there might be a way to tell git's database, "apply this specific hash
> to this particular commit and then go forward as normal."

As I understand it, that would be the equivalent to being able to forge
history in the repository.  The hash is necessarily _derived_ from the
content of the commit, including the hash of the parent commit.  To be
able to _assign_ a hash to a commit (or "blob" or whatever Git calls it
internally) would, I think, not only break the integrity assurance of
the system but wreck many of the everyday traversal operations that make
it work.

Also, if you succeeded in doing this, you would immediately impoverish
every cryptocurrency investor in the world who isn't already broke.
(It's all Merkle trees.)  They will then hire a hit man to come after
you.  Since they will only be able to pay with coins scrounged from the
crevices of the couch, you will be safe for decades.

...so you might give it a shot.

> FWIW, 1.01 is not the only hole in the git repository.  It also skips
> from 1.02 to 1.04, and later from 1.11.1 to 1.14.  However, since the
> first baker's-dozen "commits" are conglomerations of all changes made
> between early groff releases, the additional loss of information in
> missing some intervening steps is less than that resulting from
> missing the earlier starting point.

I didn't remember the details but I recall noting some gaps myself.
This is why I think it would be a bad idea to give a hostage to fortune
by respinning the whole repo history just to get 1.01 stuck on the front
of it--not that anyone seriously suggested anything so disruptive.

I'd also really like to see some groff 0.xx snapshots.  I recently
developed reason to suspect that GNU tbl was implemented in advance of
GNU troff itself, and am intensely curious to find out if that is the
case.

James Clark's discipline of maintaining radio silence since departing
the project is impressive, in a disappointing way.  Were he to chime in
occasionally as Werner does, I don't think anyone would be mean to him.
He did a lot of excellent work.

Wistfully,
Branden

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]