From the documentation, like 2 paragraphs in:

> In all modes, by default git lfs migrate operates only on the currently checked-out branch, and only on files (of any size and type) added in commits which do not exist on any remote. Multiple options are available to override these defaults.

Were your remotes not configured correctly?

▲

AceJohnny2 5 days ago | parent [-]

Let me repeat myself:

> But in my case I was converting an entire repo into one using LFS.

then check out the section in the manual "INCLUDE AND EXCLUDE REFERENCES"

▲

actinium226 4 days ago | parent [-]

OK, and your main complaint was that it added .gitattributes to all previous commits? What if someone were to go back and add a .bin to the earlier commits, you would still want it in LFS, right? I'm not sure what "cross referencing to the current commit" would mean in that case. I don't see why you would want to use the .gitattributes from a different branch, like main or something. It seems very un-git-like for an operation to reference another branch without being explicitly told to do so.

But anyway, yes, LFS rewrites history if you want to apply it to history. I agree it's sub-par; it's disruptive and risks breaking links to specific githashes.

	▲	rcxdude 3 days ago \| parent [-]
		The issue is the migration is unlike starting to use it on a repo, because the metadata propagates 'backwards in time' instead of reflecting what is actually in the repo at that commit.