I recently added many (new) files to my git repository and am tracking them with Git LFS. My remote is BitBucket and it all works nicely as intended.
Except, for every file I add to LFS, an entry is added to my .git/config that looks like this:
[lfs "https://bitbucket.org/%7B%7D/%7B********-****-****-****-****6bcd1adc%7D/info/lfs/object/verify?upload_id=********-d87a-47f9-a857-ae04********"]
access = basic
(All the *'s are hexadecimal characters I removed for security reasons)
Since one entry is added for every file I track and push with LFS and I have hundreds of files in LFS, my git config file is now huge.
I think this issue started after switching my origin remote (from one BitBucket repo to another).
What's going on and more importantly, how can I fix this?
Can I safely delete these entries from .git/config?
For reference, this is how the BitBucket remote is configured in the same config file:
[remote "origin"]
url = https://user@bitbucket.org/user/repository.git
fetch = +refs/heads/*:refs/remotes/origin/*
[lfs "https://user@bitbucket.org/user/repository.git/info/lfs"]
locksverify = false
access = basic
[lfs "https://bitbucket.org/user/repository.git/info/lfs"]
access = basic
And this is what the LFS part of .gitattributes in the root of the repo looks like:
...
database/seeds/sql/content/*/allcontent.sql filter=lfs diff=lfs merge=lfs -text
public/img/*/path1/*.normal@2x.jpg filter=lfs diff=lfs merge=lfs -text
public/img/*/path2/*.normal@2x.jpg filter=lfs diff=lfs merge=lfs -text
Update; I ran git lfs uninstall and then git lfs install --local in the repo to see if it fixes anything, it doesn't (that's to say, more lines were still being added to .git/config for new files I added to LFS). My .git/config file is now over 110KB large :S
Update 2: I was in touch with BitBucket, the only response I got so far is that this is expected behavior and something about pruning local LFS files, so I think they don't understand the issue I submitted. I suspect you can fix this the brutal way by removing the remote repository at BitBucket and all files tracked with LFS from your working directory, uninstalling Git LFS, removing the LFS directory from your Git repo, removing all .gitattributes lines that reference LFS, doing a new commit locally, using BFG or something like it to remove the references to all LFS-tracked files from all historic commits (depending on how you do it, this might make the tracked files go missing from all historical commits - I followed this article), then re-installing Git LFS and re-tracking and adding the files before pushing to a repo newly created at BitBucket. I did just this but without the final step of re-installing Git LFS - for now I'll just stick to tracking those files the regular way. If using LFS is absolutely necessary I suspect these steps will fix it (at the price of possibly losing historical commit integrity) but I'm not sure either. If I get another response from BitBucket I'll be sure to update this issue.
Update 3: BitBucket now understands the issue and is investigating.
Update 4: BitBucket never got back to me. I chose to start over afresh and now have a repo that works well without the problem. No idea what was going on.
