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

[Alejandro Colomar]

Hi Branden,

On 12/13/22 15:50, G. Branden Robinson wrote:
> Hi Alex,
>
> At 2022-12-12T16:43:16+0100, Alejandro Colomar wrote:
> > I have a plan of integrating pre-git history of the Linux man-pages
> > into the official git repository.  I have two approaches in mind:
> >
> > - Start at the first git commit:
> >
> >      commit fea681dafb1363a154b7fc6d59baa83d2a9ebc5c (tag: man-pages-1.70)
> >      Author: Michael Kerrisk <mtk.manpages@gmail.com>
> >      Date:   Wed Nov 3 13:51:07 2004 +0000
> >
> >          Import of man-pages 1.70
> >
> > And branch from it in a 'prehistory' branch which would go backwards,
> > that is, every commit would be farther in time, so the tip of the
> > branch would be the oldest tarball I can reach.  This has the benefit
> > of always being able to go farther, just by adding a commit to that
> > branch.
> >
> > - Or create a parallel branch that has nothing in common, and put it
> > in normal order, so the first commit would again be the oldest one
> > known, and then go on from there.  This one has several disadvantages:
> > (*) If we find yet an older release, you need to either rebase or
> > create a third line; (*) You can't compare against that branch with
> > git.
> >
> > I'm very likely going for the first approach.
> >
> > That may serve you, Branden; wouldn't it be nice to have those
> > prehistoric roffs in a branch that has a common ancestor with HEAD?
> > :P
>
> Neither of these approaches excites me as a change to groff's
> _development_ repo--either one could indeed be useful in a separate
> "groff archeology" project, of the read-only,
> may-get-the-entire-history-rewritten-at-any-time approach like Diomidis
> Spinellis uses.
>
> I think the backwards time-travel approach of the first would simply
> confuse me.

You can think of it as years AD and BD.  The would be commits AG and BG :)

The git horizon would be the center of the time scale.

>  And for the second, we not only have a gap at the
> "beginning" of groff history (before 1.02) but also, as Dave pointed
> out, interstitial ones as well.  Versions 1.03, 1.12, 1.12.1, and 1.13
> are all missing--perhaps others.

Yeah, a completely separate branch is more difficult to maintain.  A backwards 
time-travel is probably the most appropriate.

> This isn't to say that either of your approaches is a bad one in
> general; I simply don't think they mesh well with an active development
> repo with an incomplete pre-Git historical record.

By not being the master branch, it's not something to be considered stable 
(especially if documented as unstable).  That would allow you to rebase when 
filling gaps.

I don't see why it would be problematic.  People can simply ignore the branch 
that they don't use.  It can even be done in the git config if they want to 
permanently ignore it.

I'll certainly do it in the man-pages when I find the time to get the tarballs.


Cheers,

Alex

> Regards,
> Branden

--
<http://www.alejandro-colomar.es/>

OpenPGP_signature
Description: OpenPGP digital signature