Does git lfs migrate --no-rewrite change all the branches? And will it change the large file from history to LFS objects?

Question

In my repo, I have large files committed in history and also present in the latest commit.

I want to use git lfs migrate --no-rewrite so that the previous commit's SHAs does not get changed.

But will --no-rewrite change all the large files objects from history with LFS object?

Also, can I use --everything flag to update all the remote branches?

Answer 1

I want to use git lfs migrate --no-rewrite so that the previous commit's SHAs does not get changed.

This command, as far as I know, is not intended for migration of refs to LFS at all. Rather, it was added to correct incorrect repository state in cases where .gitattributes specifies that a file should be stored as an LFS pointer, but in fact it is stored "as is". See, for example, this answer: Git error: Encountered 7 file(s) that should have been pointers, but weren't

To understand the subject, the following links may also be useful:

• GitLab | Troubleshooting Git LFS - Encountered n files that should have been pointers, but weren’t
• The GitHub Blog | Git LFS 2.5.0 is now available - New migration modes

But will --no-rewrite change all the large files objects from history with LFS object?

No, because excluding the large file data itself directly from the repository storage by definition requires rewriting history to remove objects from it.

Also, can I use --everything flag to update all the remote branches?

The --everything flag cannot be used in conjunction with --no-rewrite because the latter results in a new commit, so only HEAD is implied and affected.