I have a repository ("repo") that needs to be gradually migrated to a new repository ("repo-lfs"). repo-lfs uses LFS to store large files, while repo did not.
The intermediate state looks as follows:
repo-lfs: ---------------> main
repo: ---------------> main
\_________ release-1.0
Now I want to migrate the "release-1.0" branch to repo-lfs, which requires rebasing repo:release-1.0 onto repo-lfs:main. I have already added repo as a remote on repo-lfs, but a naïve rebase produces conflicts for every change to every file that was migrated to Git LFS:
$ git rebase --onto <correct commit on main> repo/main repo/release-1.0
Auto-merging xy.zip
CONFLICT (content): Merge conflict in xy.zip
[...]
Could not apply 96639f9... Edited xy.zip
Encountered 1 file(s) that should have been pointers, but weren't:
xy.zip
How do I automatically resolve these "conflicts" in the obvious manner, i.e. by applying the change to the file in git LFS?
I can answer my own question now:
You do not need to use git rebase and resolve the resulting conflicts at all. git lfs migrate import is completely deterministic, which allows you to avoid the problem altogether.
As long as you do not rewrite the history of repo, you can migrate new branches to repo-lfs by simply checking them out as a local branch in repo-lfs and running the exact same git lfs migrate import command that was originally used to migrate the main branch. Git LFS will produce the exact same commit hashes it previously produced for all commits shared between the release branch and main, which means the new branch will automatically be attached to the correct parent commit and the resulting history will match the history from the non-LFS repository perfectly.