Move binary files to GLFS about docs

[adammichaelwood]

This seems like a reasonable idea.

If I read the DLFS docs correctly, this is entirely "plug-n-play" and just requires contributors to install git lfs. Does that seem correct? If so, I guess the only repo change needed is to update the contributor guide with instructions.

Am I missing anything else here?

[yanokwa]

You are correct that this just requires contributors to install git lfs.

In addition to updating the contributor guide, with installation instructions, we'll also need to add a .gitattributes file that tracks the binary files we use (e.g., png, mp4, jpg, etc). Can you send in a PR?

[adammichaelwood]

Will do.

[adammichaelwood]

So I just spent some time getting this going. In addition to installing glfs locally, you also have to remove all your existing files from your entire commit history (filter-branch) and recommit them. (cf. https://help.github.com/articles/moving-a-file-in-your-repository-to-git-large-file-storage/ )

The upshot of this is that my master is diverged from odk:master all the way back to the first commit with images.

To get everything working properly, we will need to force push this updated version of the repo over the existing one, which will likely hose up existing history a bit, but will be fine going forward. Additionally, everyone (which I think is just four of us at this point) will need to rebase or re-clone from the updated branch. Failure to do that will create potential conflicts down the line if mismatched commit histories get mingled.

So... before doing any of that... (and now, rather than later is the time to do it)-- a sanity check would be nice:

• is this actually useful and helpful?
• will it cause us more problems than it solves?
• have I done things correctly (so far)?
• what is the right/best way to pull in the "fixed" master branch over the current master? (Will a standard PR work for this?)

[yanokwa]

To confirm, there is no way to keep the existing binary files in the repo and use Git LFS going forward?

[adammichaelwood]

Well - we could keep them in the repo and then only track new binary files in glfs.
But apparently you cannot track existing files without removing them from the whole repo.
(There are a number of pages and tutorials on this point, and at least one dedicated Java tool for handling the migration to GLFS.)

So - I guess we could just move forward with new files and orphan the 113 existing media files. (That seems bad and wrong somehow.)

One (potentially stupidly simple) thing I didn't think of until just now... I wonder if it is possible to simply delete all the images, commit the delete, and then add them back in and commit the add. I don't know why that wouldn't work (I'm going to go try it right now), but NO ONE mentions doing it that way in any of the glfs tutorials.

[yanokwa]

I'm comfortable having the four of us having to reclone, but I'd like @lognaturel to confirm that she thinks this is a good idea.

I'd also propose that I make those changes. That is, @adammichaelwood will send me the commands, I'll try them out and confirm they work and then I'll do the force push.

[adammichaelwood]

okay, well -- i feel kinda dumb for not trying this earlier -- AND -- i don't know why no one else has done this, but:

Based on some experimenting, if i simply:

• delete relevant files
• commit
• add files back in
• commit

Then the newly committed files ARE tracked by GLFS, as shown by running git lfs ls-files

This tells me that all the rebasing and recloning and filter branching described in the tutorials is not at all needed. I just need to pull a clean fork of current master, make the relevant changes, and submit a normal PR.

I will do that shortly (after lunch).