We are currently migrating from CVS to a git repository. One team however already used cvs2git about a year ago for their repository because their new feature needs a lot of moving files with history which CVS is historically not very good at. The repositories both should then use GIT-LFS for our bigger checked in sources (pre-built external libraries, for example)
The idea was to create the same starting point for merging all their changes with history onto our repository once we migrate.
So I already have an exact replica of the starting point; the idea was to create now all the patch files with git format-patch. Now most of the patches are working fine, the problem is just with patches that use git lfs.
an example:
diff --git a/Foo/bar/baz.zip b/Foo/bar/baz.zip
new file mode 100644
index 00000000000..6fce3f4bd05
--- /dev/null
+++ b/Foo/bar/baz.zip
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:c90b657621e07fa40476186d94e2f6e06f055b49294b83ee976f73dfac120d86
+size 116056
--
2.13.2.windows.1
when I try to apply that patch, the following happens:
$ git am ../patches/mypatch.patch
Applying: #someTfsId: myCommit
Downloading Foo/bar/baz.zip (113.34 KB)
Error downloading object: Foo/bar/baz.zip (c90b657): Smudge error: Error opening media file.: open D:\repositories\myrepo\.git\lfs\objects\c9\0b\c90b657621e07fa40476186d94e2f6e06f055b49294b83ee976f73dfac120d86: The system cannot find the file specified.
Errors logged to D:\repositories\myrepo\.git\lfs\objects\logs\20171006T110837.3254847.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: Foo/bar/baz.zip: smudge filter lfs failed
user@machine MINGW64 /d/repositories/myrepo (develop|AM 1/1)
$ git am --abort
my next idea was to use the original repository and get all lfs objects with GIT_TRACE=1 git lfs fetch --all afterwards I tried to copy that one object (for testing purposes) which resulted in
user@machine MINGW64 /d/repositories/myrepo (develop)
$ git am ../patches/mypatch.patch
error: Foo/bar/baz.zip: already exists in working directory
Applying: #someTfsId: myCommit
Patch failed at 0001 #someTfsId: myCommit
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
So I suppose the question is: is it possible for me to add the LFS objects to the remote server, or do I have to "un-lfs" the repository that is used to create the .patch files, so the binary diffs are stored in the .patch files?
We really want to keep the history and at the moment the amount of patches would be about 1600 commits, which would be hard to do by hand.
If I am missing some obvious way I am happy for any constructive input
I know this question is quite old but I was just faced with this scenario today.
This is the way that I have solved the issue, perhaps there is a better way but this worked for me.
The basic steps are:
Note: any uncommitted work will be lost in step 2 so be careful
Lets say I have a file called opensrc/src/make-4.3.tar.gz in the repository and I am at the top level of the repository. I want to create a patch that includes that file and the other files that were changed along with it but my tracked files are:
Go ahead and add and commit your files that will be part of the patch. You can find out which files are going to be in LFS by performing:
So before I create the patch I add this file (and any others) to the exclude list:
Now checking lfs status again:
and now create the patch:
Now you can revert the LFS change and recommit the original so that your file ends up in LFS:
NOTE: your patch will also exclude the file(s) from LFS so you may have to fix that by resetting the commit, editing .gitattributes and then recommitting