Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to I disable git-lfs?

Tags:

git

git-lfs

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?

like image 520
Shadow Avatar asked Feb 09 '18 05:02

Shadow


People also ask

Is Git LFS installed by default?

$ git lfs install Git LFS initialized. You'll only need to run git lfs install once. Once initialized for your system, Git LFS will bootstrap itself automatically when you clone a repository containing Git LFS content.

Is Git LFS necessary?

Absolutely! If you insist on using Git and insist on tracking many large files in version control, you should definitely consider LFS. (Although, if you are a heavy user of large files in version control, I would consider Plastic SCM instead, as they seem to have the most mature solution for large files handling.)


4 Answers

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.

like image 58
Shadow Avatar answered Oct 21 '22 22:10

Shadow


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

  1. Verify you actually have LFS files with git lfs ls-files.
  2. 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.
  3. Commit any changes you made to .gitattributes.
  4. Make sure you have no changes with git status.
  5. Run the migration: git lfs migrate export --everything --include .
  6. Run git status to make sure you have no changes. If you left .gitattributes with filter=lfs you might incorrectly have changes now.
  7. Verify all the previously listed LFS files are no longer present with git lfs ls-files.
  8. 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...
like image 39
Doug Richardson Avatar answered Oct 21 '22 22:10

Doug Richardson


For particular file

  1. Remove file/pattern from .gitattributes
  2. Go to file dir and run touch myfile.bin
  3. Commit and push changes
like image 2
Kamil Kiełczewski Avatar answered Oct 21 '22 23:10

Kamil Kiełczewski


Based on the answer of Shadow I modified entire history update a little. For the ones, who do not want to keep LFS files (which in my case I did not, because they would've been huge).

Use:

GIT_LFS_SKIP_SMUDGE=1 git filter-branch -f --prune-empty --tree-filter '
  git lfs checkout
  git lfs ls-files | cut -d " " -f 3 | xargs rm -f
  git rm -f --ignore-unmatch .gitattributes
' --tag-name-filter cat -- --all

Also it does not fail when no .gitattributes is present in a commit, which again, in my case was not true for all the commits.

Also the repo did not have the original LFS files stored in remote, hence the usage of GIT_LFS_SKIP_SMUDGE=1

This way the repo does not include any LFS references and files, which makes cloning the repo faster and lighter - which was my goal. Large files were used for tests anyway, but since code has improved a lot, running those old tests is irrelevant.

like image 1
arapEST Avatar answered Oct 21 '22 23:10

arapEST