From a clone of a from a Git repository that supports LFS, I want to push to a new remote Git repository that does not support LFS.

The current clone shows a number of LFS files when I use git lfs ls-files --all.

I created the new Git repository using git init --bare d:/new_repo.git.

Then I added the new Git repository as remote using git remote add new d:/new_repo.git.

When doing git push new master, the following error is generated:

Uploading LFS objects:   0% (0/10), 0 B | 0 B/s, done.
batch request: missing protocol: "d:/new_repo.git/info/lfs"
error: failed to push some refs to 'd:/new_repo.git/'

As I understand, the problem is that Git LFS is not supported in the Git repository new_repo.git. However, that is actually what I want, since I want to avoid the LFS files in the new repository, and just have a regular Git repository without LFS use.

How to make Git push from repository with LFS support to a remote repository without LFS support?

Or is there some basic Git or LFS concept that I have misunderstood, so this question does not make sense ? :-)

CodePudding user response：

Or is there some basic Git or LFS concept that I have misunderstood, so this question does not make sense ? :-)

Unfortunately, yes.

Think of Git-LFS as this:

===========         ===========
|   Git   |         | Git-LFS |
|---------|         |         |
| commit1 |         |   the   |
| commit2 |         |   big   |
|    :    |         |  files  |
| commitN |         |         |
===========         ===========
  server1             server2

When you use Git-LFS, Git never even sees the big files. They go over in the Git-LFS box. They're stored on a different server. The Git repository, stored on server1, does not have the files.¹

If you duplicate the Git repository—which is how Git does this sort of thing—you get a copy of a repository that doesn't have the big files. If you LFS-duplicate the pair of storage systems, you get a second repository that also doesn't have the big files, but you get a second big-file-server that does have the big files.

It is possible to take an existing Git Git-LFS repository-and-big-file pair, grab each commit from the Git repository, add in the big files from the LFS repository, and use that to make a new commit in a new repository that doesn't use a "server2" to store the big files at all. The new repository would be incompatible with the old repository. This is simply the reverse of the process that git lfs migrate import uses to take a repository that has big files and convert it to an incompatible small repository and separated-out big files.

What you need, then, is git lfs migrate export, which does in fact exist. There seem to have been some bugs in it and as the link here shows, at least some of them are still marked "open". I don't know how usable this is for your particular setup.

Remember that a "large" repository (with the large files in it) is entirely different from an "LFS" repository (with "dummy" files in it, as in footnote 1). You cannot mix the two, even though you can—given the presence of a "server2" LFS server—convert back and forth.

¹Instead of the large files, the Git repository has small "dummy" files. These are not really dummies as they contain crucial information for locating the large files in the LFS server, but they are all Git has, and they don't have your file content. So the repository—the part that Git has, in its commits—simply doesn't hold the desired data, and copying that repository is thus destined to fail. Git's commit-data-integrity system prevents substituting in the real files for the dummy files, as the real files have different (and of course much larger) data than the dummy files.