2

Problem: git lfs migrate import converted everything to hash including .gitignore and all plaintext files.

Locally I gained 10k untracked files in .cache and .vscode-server maps that I do not want to track.

Even worse I can't edit any text files -> everything turned into 3 line file with hash!

Remote Github files now all are: Stored with Git LFS

Even my .gitignore looks like as follows:

version https://git-lfs.github.com/spec/v1
oid sha256:5dc008478f60b91b2ca91405adf351b4d253a254cd77604fe3a86bba855eac8e
size 7036

Short history

  • Local git repo added a large .bak file. Push to remote(Github) thus failed.
  • Installed LFS locally (technically a different dev machine via SSH)
    git lfs install
    git lfs track "*.bak"
    git add .gitattributes
    git lfs status
    git lfs migrate
    git lfs migrate info
    git lfs migrate import
    git pull
    git push

Last 3 lines must be bad mistakes - especially git lfs migrate import

I should have specified which file types to import. See Git LFS git lfs migrate import include all file types specified in .gitattribute?

My .gitattributes file turns out to contain all extensions

*.bak filter=lfs diff=lfs merge=lfs -text
*.bash_history filter=lfs diff=lfs merge=lfs -text
*.gitignore filter=lfs diff=lfs merge=lfs -text
*.ipynb filter=lfs diff=lfs merge=lfs -text
*.md filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text
*.json filter=lfs diff=lfs merge=lfs -text
*.txt filter=lfs diff=lfs merge=lfs -text

more file types follow

I only wanted to convert .bak (and possibly .zip) to LFS.

How do I fix this mess?

First priority is getting original text files(.txt, .gitignore, .json, .md, .html etc) back locally.

Second priority is actually pushing to remote.

Sint
  • 1,580
  • 3
  • 21
  • 38
  • 1
    Do you have a backup of the repository from before the "migrate" operation? That's probably the easiest place to go. Otherwise: let git-LFS do the working-tree-file substitutions, copy the working-tree files out for each commit you want to redo, then build a new Git repository one commit at a time and throw away the old one (this will be painful). – torek Jan 27 '22 at 10:39
  • No backup, I guess I could clone the revision from Github before LFS was added, then manually add the missing files one by one. – Sint Jan 27 '22 at 10:56
  • 1
    Yes, that's the painful option. – torek Jan 27 '22 at 11:03

2 Answers2

1

If you want to keep using Git LFS but just want to restore files to have their contents, use git lfs checkout.

Liron Yahdav
  • 10,152
  • 8
  • 68
  • 104
0

So far the least painful answer was to revert manually by each file type

 git lfs migrate export --include="*.gitignore" --everything
 git lfs migrate export --include="*.json" --everything 

and so on

PS. This involved manually upgrading git-lfs from 2.3.4 to 3.0.2 as git lfs migrate export was simply broken in Ubuntu 18.04LTS version.

EDIT: turns out this only works for the local version as now I can't pull from remote. Naturally no push either.

> git pull --tags origin master
 * branch            master     -> FETCH_HEAD
fatal: refusing to merge unrelated histories

So now I will have to create a new remote...

Sint
  • 1,580
  • 3
  • 21
  • 38