Hacker News Reader

Comment by PMunch | Hacker News Reader

Wouldn't Git LFS be the tool for this job? Have the automated tool build a .zip file for example of the translations (possibly with compression level set to 0), then have your build toolchain unzip the archive before it runs. Then check that big .zip file into GitLFS, et voila you now have this large file versioned in Git.

View on HN

Git LFS isn't the same as git, though. It's better than putting everything in a separate store, but for one it disables offline work, and breaks the concept of D in the DVCS of git.

> then have your build toolchain unzip the archive before it runs

My build toolchain shouldn't have to work around the shortcomings of my environment, IMO.

> et voila you now have this large file versioned in Git.

No, it's on a separate http server that is fetched via git lfs. Subtle, but important difference.

> it disables offline work,

This is a non-issue for images and autogenerated files, since you shouldn't ever be doing a merge on them.

> breaks the concept of D in the DVCS of git.

git-annex is distributed and works well for files that will never be merged (such as images, or autogenerated files)

It's good enough for the small usecases, but way behind tools that have first class support for binary files (binary deltas, common compression, ...). Even SVN shines here.

Separately we also found that git lfs is not very optimised for large repositories, notably its locking feature which list every file tracked by git for every checkout and commit command.

Reply on news.ycombinator.com