<div dir="ltr"><div>Hi</div><div><br></div><div>This is a follow up to my post yesterday, which introduced the large scale basics of git pack files. This post is how to get data into git, and retrieve it, without using git as a version control system. Here we consider only one data stream at a time.</div><div><br></div><div>Here's yesterday's post (which contains the details for tonight's TeX Hour, 6:30pm UK time).</div><div>Idea: Git as basis for future CTAN and TeX Live.<br></div><div><a href="https://tug.org/pipermail/tex-live/2021-June/047161.html">https://tug.org/pipermail/tex-live/2021-June/047161.html</a><br></div><div><br></div><div>A BASIC EXAMPLE</div><div>Every file known to kpsewhich has a git hash, computed as follows.</div>$ kpsewhich story.tex<br>/usr/local/texlive/2019/texmf-dist/tex/plain/knuth-lib/story.tex<br>$ cat $(kpsewhich story.tex) | git hash-object --stdin<br>fcbaa4151af32191e6b3e35c90cea8af8ad8fa03<br><div><br></div><div>Let's store this data in a Content Addressable Store. First create the store</div><div>$ git init cas-example.git<br>Initialised empty Git repository in /home/jfine/cas-example.git/.git/<br>$ cd cas-example.git/<br></div><div><br></div><div>Now add the data to the store. The -w means write the file to the store.</div><div>cas-example.git $ cat $(kpsewhich story.tex) | git hash-object -w --stdin<br>fcbaa4151af32191e6b3e35c90cea8af8ad8fa03<br></div><div><br></div><div>Here's the data we just added</div><div>cas-example.git$ find .git/objects/ -type f<br>.git/objects/fc/baa4151af32191e6b3e35c90cea8af8ad8fa03<br></div><div><br></div><div>Now let's get the data back again. We use the git hash as the key.</div><div>cas-example.git$ git cat-file -p fcbaa4151af32191e6b3e35c90cea8af8ad8fa03<br>\hrule<br>\vskip 1in<br>\centerline{\bf A SHORT STORY}<br>\vskip 6pt<br>\centerline{\sl    by A. U. Thor} % !`?`?! (modified)<br>\vskip .5cm<br>Once upon a time, in a distant<br>  galaxy called \"O\"o\c c,<br>there lived a computer<br>named R.~J. Drofnats.<br><br>Mr.~Drofnats---or ``R. J.,'' as<br>he preferred to be called---% error has been fixed!<br>was happiest when he was at work<br>typesetting beautiful documents.<br>\vskip 1in<br>\hrule<br>\vfill\eject<br></div><div><br></div><div>DISCUSSION</div><div>From \input story.tex, TeX obtains an input stream. In TeX Live there are two steps. The first step is to use kpsewhich to produce a file path to the data stream. The second step is to open the file for reading. This is the input stream that TeX reads.</div><div><br></div><div>This process relies on the data to be streamed being available in a local store (or otherwise). That local store is here a part of the ordinary filesystem on the computer.</div><div><br></div><div>Here's another way to resolve \input story.tex into an input stream. It requires some preparation up-front (as does kpsewhich - the lsR database). First we store all the data we wish to stream in a git content addressable store. Second, we create a database with entries such as</div><div>story.tex fcbaa4151af32191e6b3e35c90cea8af8ad8fa03</div><div><br></div><div>This second database is analogous to the ls-R database. By the way, git can store this database as a tree object, which has a git hash of its own.</div><div><br></div><div>It's important to note that the data is decompressed on the fly. And that because stored at the git hash, there's no duplication of data. Thus, two trees with only a few changed files can be stored together efficiently.</div><div><br></div><div>Expert users will know that kpsewhich can modify its search depending on the 'engine', such as tex, pdftex, latex, luatex. This can be accommodated by having the engine as the parent tree entry. Indeed, one can even use the release year as a grandparent. This would all ALL DATA FILES for ALL ENGINES and ALL YEARS to be stored in a single git repository.</div><div><br></div><div>The command line samples above could be extended to produce such a repository and associated year-engine-kpsewhich access trees.</div><div><br></div><div>We don't yet know how big this single git repository will be. My immediate estimate is 10 GB, of which 5 GB will be fonts. Recall that about 5GB is the repository size limit on Github.</div><div><br></div><div>Further work would be required to support random access to a data stream. I don't know which programs in the TeX suite use such random access, and when.</div><div><br></div><div>-- </div><div>Jonathan</div></div>