问题
I have a repository on bitbucket that is using LFS. Since using it for some time, I've decided to move the repository back to a space under my control. The only reason I used LFS in the first place was to effectively double my repository size limit (as files in LFS go in a separate bucket) but now I'm moving it, I no longer need to do this.
I need a way to trawl through the entire git history, removing all traces of the work git LFS does (so all files are committed 'normally'). Once this is done, I intend to force push to the new repository.
I've done quite a bit of searching, and come across suggested solutions but I don't understand how to implement/run them because they are high-level.
How do I wave goodbye to git LFS?
回答1:
Update current commit only
If you want to move off LFS, but are not so worried about fixing the entire git history, you can do the following;
git lfs uninstall
touch **/*
git commit -a
This will uninstall LFS support, touch every single file (so that git recognises that is has changed) then commit them all. If you like you could be more specific (ie, **/*.png
for example). Note that using **
requires extended glob support enabled (shopt -s globstar
on bash)
Update entire history
This worked for me - but it throws lots of errors (I think I'm getting an error for every commit that a file hasn't been added to LFS in) and takes a long time (roughly 2-3 seconds per commit).
git lfs uninstall
git filter-branch -f --prune-empty --tree-filter '
git lfs checkout
git lfs ls-files | cut -d " " -f 3 | xargs touch
git rm -f .gitattributes
git lfs ls-files | cut -d " " -f 3 | git add
' --tag-name-filter cat -- --all
It uninstalls git LFS support (theoretically preventing LFS from messing with the index) then for each commit it makes sure the LFS files are checked out properly, then touches them all (so git realises they have changed), removes the settings for LFS found in .gitattributes
so that when cloning it doesn't keep trying to use LFS, then adds the real file to the index.
After you do the above, you will need to do a force push. Naturally, that'll throw anyone else working on your repo into a detached head state - so doing this during a code freeze is wise. Afterwards, it's probably easiest to get everyone to do a fresh clone.
回答2:
git lfs migrate export
From git lfs migrate help
:
Export
The export mode migrates Git LFS pointer files present in the Git history out of Git LFS, converting them into their corresponding object files.
Example Workflow
- Verify you actually have LFS files with
git lfs ls-files
. - Remove all
filter=lfs
lines from ALL the.gitattributes
files in your repo..gitattributes
can live anywhere so make sure you find them all otherwise this can cause migration issues later. - Commit any changes you made to
.gitattributes
. - Make sure you have no changes with
git status
. - Run the migration:
git lfs migrate export --everything --include .
- Run
git status
to make sure you have no changes. If you left.gitattributes
withfilter=lfs
you might incorrectly have changes now. - Verify all the previously listed LFS files are no longer present with
git lfs ls-files
. - Inspect files (e.g., open formerly LFS files to make sure they aren't corrupt) and run your build to make sure everything works.
Tips
- Run on case sensitive file system, in case you have file system collisions (e.g. ./LICENSE and ./License) at some point.
- Git rid of all your
filter=lfs
lines from ALL your.gitattributes
. - You may also want to delete LFS remains in
.git/hooks
directory: pre-commit, post-commit, post-checkout, post-merge. - With
$GIT_TRACE=1
there should be no sign of...trace git-lfs: filepathfilter: accepting...
回答3:
For particular file
- Remove file/pattern from
.gitattributes
- Go to file dir and run
touch myfile.bin
- Commit and push changes
来源:https://stackoverflow.com/questions/48699293/how-to-i-disable-git-lfs