Git-lfs: Fix somebody else's lfs goof. Instruction for dummies?

[pauljohn32]

Similar things are discussed in old posts, but this one https://github.com/git-lfs/git-lfs/issues/1726 says git-lfs versions are changing and people with my question should open new questions rather than ask about old versions. So that's what I'm doing here.

We have an lfs repo that works fine.

A person who does not have git-lfs clones the repo, then adds some binaries (say, pdf), and then pushes back. Now the other users see messages like this:

$ git merge pg-branch
Auto-merging lit/overview/Websites.md
CONFLICT (content): Merge conflict in lit/overview/Websites.md
Automatic merge failed; fix conflicts and then commit the result.
Encountered 3 file(s) that should have been pointers, but weren't:
        lit/overview/Smith.pdf
        lit/overview/Jones.pdf
        lit/overview/Baker.pdf

What is the most direct route to convert those pdf files to lfs references, push that branch back to server so that the files are correctly understood?

And then what do we tell the other users to do in order to clean out that branch? Will git pull in there be sufficient to put those things back in the right spot?

In this post (https://github.com/git-lfs/git-lfs/issues/1939), I find discussion of "git lfs migrate import" but I don't understand the syntax of what I'm supposed to do, or how the repository is to be made sane again for all of the git-lfs systems where users ran "git pull" and that branch came in with unwanted PDF.

[larsxschneider]

👋 @pauljohn32! The easiest way is this:

git rm --cached <PROBLEM FILE>
git add --force <PROBLEM FILE>
git commit -m "Move files properly to GitLFS"

This would copy the content of your PDF files from pure Git to Git LFS. The drawback of this method is that the current version of your content stays in pure Git's history (which might increase the size of your repo). Every future update of the content will be only in Git LFS though.

@ttaylorr : Would it make sense to add these instructions to the Git LFS "should have been pointers" message?

If you want to move historic content to Git LFS then you could try something like this:

git lfs migrate import --verbose --everything -I="*.pdf"

However, I wouldn't recommend that unless the PDF files are really huge. This method rewrites the history which could open a can of worms for big teams.

If you want to learn more about Git LFS then my talk on the topic might be useful for you.

[JGJP]

I was successful using git lfs migrate import as mentioned in #1939.

In your example you would run git lfs migrate import --include="*.pdf" and then commit the files as lfs pointers. I would like it if the migrate command resulted in a clean status but I don't know enough about the intricacies to comment further.

I think a git-endorsed standard workflow would be appreciated by many, as this would seem to be a common theme when working with new developers. It's easy to forget that git lfs needs to be installed separately and then additionally hooked into git with git lfs install

[ttaylorr]

@ttaylorr : Would it make sense to add these instructions to the Git LFS "should have been pointers" message?

I think that could be useful, yes!