Git LFS Support - Reopened

[Kaauw]

Hello Team,

I reopen an old case that was opened last year about git lfs support : #176.

I think it still must be supported by Mike as it's a git feature, and verry useful for to store assets within the codebase without overloading the git history.

We moved our internal documentation to Git LFS. We save amoung 2.2 gigabit of git history and it drastically reduced the repository size.

Here the number of files :

git lfs ls-files | wc -l
425

Overwere, Mike doesn't support git lfs and simply bypass the repository's git configuration. For my understanding, here my questions :

• Why this kind of bypass exists as you rely on the git command ?
• Why doesn't simply support Git LFS ? The arguments provided in Support for Git LFS? #176 are quite strange, I don't understand your position. Everyone have different setup and having a specific step to store binaries can be quite huge to put in place when we can simply rely on Github or Gitlab LFS setup.
• In the case it's a lack of time to implement that, what needs to be done on the codebase to support Git LFS ?

Regards,

Ben

[jimporter]

• Why this kind of bypass exists as you rely on the git command ?

mike just uses git fast-import to generate commits, so any such bypass is occurring within Git. As for why, I'd have to guess that's it's because LFS isn't actually a Git feature. It's a (popular) extension for Git.

• In the case it's a lack of time to implement that, what needs to be done on the codebase to support Git LFS ?

I had looked previously when #176 was filed, and any solution seemed at least relatively complex. If it turns out there's a very simple fix for this (a few lines of code), then that would be great. Someone could write a patch and (if it truly is simple), I'd merge it. However, if it's as complex as it seemed, I don't think I'd merge the change. As mentioned in #176, mike is already significantly more complex than I'd like it to be. I'd prefer not to add any more features or dependencies on external packages.

More generally, mike is intended primarily to make it easier for small hobbyist projects to host multiple versions of their documentation. For more complex scenarios (including large files), I'd recommend just using a regular web server. Generated documentation really doesn't belong in a Git branch at all: it's not source code, it's a release artifact. The only reason mike puts generated docs in a Git branch is to make it easy to use with Github.