Repo in inconsitent state after --convert-to-git-lfs

[davideberlein]

First of all: Thanks sooo much for this awesome tool! It has helped our SVN2GIT migration A LOT!

I have a repo with some large *.jar files and am using BFG --convert-to-git-lfs to move these (including their history) to LFS.

The way I am doing it is the following:

bfg --convert-to-git-lfs '*.jar' --no-blob-protection

on the root of my repo. It seems like BFG-cleanup leaves the repo in an inconsistent state after its execution or maybe I am doing something wrong. After the execution of the command I see this:

All of the *.jar files are staged as modified and the .gitattribute files are staged as deleted. Seems like BFG adds them to LFS but then reverts this for some reason. Now I have the following behaviour:

• If I push the current state of the repo just leaving the files staged The *.jar files are referenced as lfs files but aren't uploaded to the server (I only get the git-push and not the git lfs uploads logs and the server (Bitbucket Server) says the files are managed by LFS but can't be found).
• If I commit the staged files and then push the repo the *.jar files are not treated as LFS files and fully managed via git in a consistent state. --> Not what I want
• If I RESET the staged files and push this state, the files are correctly linked as LFS files and I also see the lfs upload in the push log. Bitbucket recognises the files and they can be cloned...

Is this as designed or am I doing something wrong or is this a bug? I can send you a version of the "uncleaned" repo to reproduce.

Best Regards

David OS: MAC OSX 10.11.3 GIT: 2.5.4 GIT-LFS: 1.1.1 BFG: 1.12.5

[rtyley]

Glad the tool is helping you! Sounds like you're doing this is in a normal 'working directory' repo rather than a bare one?

Things can get confusing (not exactly broken, just confusing) for this particular operation if you're using a 'working directory' repo rather than a bare one - the BFG changes all of your history (even your latest commit, if you use --no-blob-protection), but doesn't change your working files. This means even if you started out with a clean working directory with no changes, you'll magically see 'changes' in your working directory after the BFG run - the BFG has changed your latest commit, and that's now different to your working files (which haven't changed) - so it confusingly appears that you have some new changes to commit - and they're the exact opposite of the ones you want to do!

I always recommend using a bare 'mirror' clone of your repo for BFG operations: it gives you a copy you can safely screw up, and there's no potential for confusion with the working directory.

https://github.com/rtyley/bfg-repo-cleaner/releases/tag/v1.12.5

If I RESET the staged files and push this state, the files are correctly linked as LFS files and I also see the lfs upload in the push log. Bitbucket recognises the files and they can be cloned...

This is the correct way to resolve your problem - do a git reset --hard and your working directory now correctly resembles your changed history.

If the BFG has helped you with your project, please consider supporting development of the BFG and donating to https://www.bountysource.com/teams/bfg-repo-cleaner

[davideberlein]

Hey, thanks for your fast response, that makes a lot of sense! The strange thing though is, that pushing the current state after BFG has run without committing or resetting the staged files should also work shouldn't it? Because in my case this ended up in an inconstant state on the pushed server (see my initial comment)