Remove Large Media from shivjm.blog

Support
, , ,
#1

Hello. Please remove the Large Media extension from my site at https://shivjm.blog. I confirm that I’ve read the support guide and have the repository checked out locally (I’m not sure whether that qualifies as having local backups or not). I’m migrating to my Git host’s LFS support, so my understanding is that, once I receive confirmation from Netlify, I should delete .lfsconfig and set the GIT_LFS_ENABLED environment variable in the UI.

Could you please explain to me how the migration works for historical files? I’m not sure I understand how the other host seamlessly takes over, even for media in older revisions.

EDIT:
I ran git lfs migrate export locally. I don’t see any changes in my repository status—I still have .lfsconfig, in case that matters—but I did see it fetch a bunch of appropriately sized images after this output:

migrate: Fetching remote refs: ..., done.
migrate: Sorting commits: ..., done.
migrate: Rewriting commits: 100% (0/0), done.
migrate: Updating refs: ..., done.
migrate: checkout: ..., done.
prune: 996 local objects, 211 retained, done.
#2

Hi, @shivjm. We have removed the Large Media add-on from the site now.

Would you please push the commit removing .lfsconfig to the upstream repository? This will trigger a new build.

Please keep in mind that you might want to run the command below after deleting the .lfsconfig file:

git lfs push --all origin

This will sync the local repo’s LFS objects with the Git LFS service at the original Git host. It pushes any new binary blobs to their LFS service which may have been added after you moved the LFS service to Large Media.

Please let us know if there are any issues with the new build or deployed site.

#3

Looks like what I thought was the backup wasn’t a backup—it’s not enough to just have the repository checked out, and now I’m missing files. I believe I was meant to run git lfs fetch --all origin to get the ‘local backups’.

I can restore them from various out-of-band backups, fortunately, and git lfs ls-files -a shows me which ones are only pointers. I’m just not sure how to insert the objects into the LFS store so it doesn’t try to fetch them from Netlify.

EDIT:
I can’t restore most of the files, as it turns out, only a few of them. I’d still like to know how to insert them into the store, though.

#4

Hi, @shivjm. The command to track a file in LFS looks like this:

git lfs track <filename here>

You can also use a wildcard like so:

git lfs track "*.jpg"

There is more complete documentation about Git LFS here:

Also, when using Git LFS at Netlify (and not using Large Media), please remember to set GIT_LFS_ENABLED.

#5

I’m sorry, but it doesn’t look to me like you’ve read more than a few words here and there of either of my messages, given that you ignored my questions in the first one (answering which would have prevented me from losing data because of my misunderstanding) and are now answering a different question from the one I asked. I’ll try to figure it out on my own. Thanks anyway.

#6

Hi, @shivjm. Slow your roll there. There is no need to get rude and I’m also fairly certain you should still have all the Git LFS data.

I do agree I did miss one (and only one) question from you but that doesn’t justify being insulting.

You said you were ready to proceed with the Large Media add-on removal. You did not say to wait until you were sure you were ready. You wrote this:

You said to remove it and we did so. If you lost data, that is not my fault. We told you to be sure before making the post.

The answer to your question (the only question and one that I missed) is that you should have run this command:

git lfs fetch --all

However, as this is your personal blog site, I’m guessing that no one else is committing to that repo. If so, your local system should have all copies (past and present) of the Git LFS files as your local repo is the one creating the commits that get pushed. You cannot push a commit without the data existing locally. This means all versions of the Git LFS file must have existed locally at some point. If your local repo is the only local version, the command above normally isn’t required (and if you do run it nothing changes).

So, in most case even if you didn’t run git lfs fetch --all, the data should exist locally. If so, the process to push the data to GitLab (the upstream repo host), the workflow is just this:

  • delete the file .lfsconfig from the repo
  • add that change to a commit and push it upstream
  • run git lfs push --all origin

Removing .lfsconfig changes the Git LFS service from Large Media back to GitLab. That final command is what pushes the local objects to GitLab’s Git LFS service.

Now, if you did not have the copies in the local Git repo, that won’t work. For example, if you deleted the local repo directory and then made a fresh clone of the repo without running the command above, then yes, you did delete the older copies of the files. However, the current versions should still exist. If even the current versions are missing, that is very unusual. I’d need a complete accounting of the changes you have made to the repo to explain it if that is the case.

I hope this helps. If not, please feel free to reply anytime as long as you are respectful when doing so.

#7

Hi @luke. Let’s be clear about a few things, please:

  1. Telling you (correctly, I hope we can both agree after this) that you didn’t read my messages thoroughly is neither rude nor disrespectful. As a fellow IT professional with past experience in support, I was extremely careful to couch it in bland terms while still conveying my disappointment. You might not like it being pointed out, but that is not the same thing as my insulting you. I’m quite perplexed to hear this.
  2. As regards ‘one (and only one question)’, I can see that ‘I’m not sure whether that qualifies as having local backups or not’ should have been phrased more explicitly as a question, and perhaps it would be more accurate for me to say ‘concerns’ rather than ‘questions’.
  3. This is a response to something I didn’t say. I made the mistake and the responsibility is mine; my second message asking about the store is entirely about recovering. Meanwhile, here’s what I did say in my last message: Had you clarified that a clone of the repository is insufficient, I would have asked you to wait. The fact that you didn’t doesn’t make you responsible, since I’m still the one who asked you to do it. It just means you had an opportunity to stop me from making a mistake.

I must say, I was a big fan of Netlify before this. After my botched migration, I would simply have suggested clarifying the bit about local backups in the docs… had we ever reached that point. Even your second reply only resigned me to continuing my attempts to repair the history on my own, which I honestly wouldn’t expect Netlify to do much about anyway, given that it’s an odd and complex situation arising from my mistakes. However, the defensive response and personally offended tone in this most recent message are hard to understand.

At any rate, coming back to the subject:

Yes, the current files do exist. It’s historical files from older commits that are missing. I have no idea why Git LFS deleted the objects locally, as I’m using the same clone as before and have never interacted with LFS beyond adding files. I’ve spent the past few days trying various approaches to edit the old commits to insert placeholder images without triggering a Git LFS fetch and without breaking my history. I’ll keep trying.

#9