> On Aug 13, 2021, at 7:53 PM, Rob Sargent <robjsarg...@gmail.com> wrote:
>
>
>
>> On Aug 13, 2021, at 6:54 PM, Mark Barton <mbarto...@gmail.com> wrote:
>>
>> Ken,
>>
>> You could consider using git-lfs, Large File Support. There is some setup
>> and then you can say track *.pdf and that will tell git to track the binary
>> file in a more efficient way. I use this mailing for csv files that I want
>> to have a snapshot version of with the Jupyter notebook that used them. Once
>> you are tracking the files with git-lfs, they will be tracked with the
>> normal git commits.
>>
>> I agree that the best practice is not to commit these types of files, but
>> sometimes it is handy to. By committing the PDF files to the repo, I can use
>> Working Copy, a git client, on my iPad to quickly reference a document.
>> Since the iPad cannot run Emacs, I am unable to regenerate the PDF from
>> there.
>>
>> Mark
>
> If you’re using GitHub or gitlab you can place artifacts along side your code
> repo. One often sees executables and jars there. Typically built and updated
> by mechanisms on the holster on a “release” action or similar event
I see autocorrect preferred “holster” to “hoster”
