How do you handle attachments when using sync via git

Hello,
I use Obsidian for quite some time now and synced my vault via git. Since I am tech-savvy and do like git, I want to keep it that way. I always avoided using many attachments, since I don’t want to unnecessarily increase the size of my git repo with binary files. However, recently attachments came in really handy, and in the future, I do want to keep a lot of attachments. Therefore I am looking for the best way to integrate them into git. Currently I’m aware of two options:

    1. Using git LFS to store all the attachments. However, I don’t know how I could set up git-lfs efficiently since I currently use github as a remote storage, and git-lfs storage is really expensive on there.
    1. Putting the attachments folder on .gitignore and syncing them for example via google drive. However, this option does not look clean to me.
      Does anyone have a best practice for this case?

This is the way I do it for large attachments.

I have a Templater script that I use to insert the Drive links, which lets me paste the direct link and it converts it to a nice embedded iframe which shows a preview of the file.

This means that videos can be played directly from within the note, documents are directly editable from within the note, etc:

Templater template:

<iframe src="<% tp.user.driveLink(tp) %>" style="border:none;height:300px;width:500px"/>

Templater user script:

async function main(tp) {
    const link = await tp.system.prompt('Enter the Google Drive file link')
    if (link && typeof link === 'string') {
        if (link.startsWith('https://drive.google.com/file')) {
            return link.replace(/\/view[^/]+$/, '/preview')
        } else if (link.startsWith('https://docs.google.com/')) {
            return link.replace(/\/edit[^/]+$/, '/preview')
        }
    }
    return ''
}
module.exports = main
2 Likes

Hey, thanks for your answer, this solution seems interesting to me. As far as I can see you replace the desired drive links. I’m not proficient in writing JavaScript code but is it possible to set an environment Variable and make the links dependent on that variable? For example I got a variable called obs_env and my link would be ${obs_env}/some/path. So I could use different local paths on different machines?

I’m not creating local paths, I’m merely changing the Drive web link to be it’s own preview format.

eg

https://drive.google.com/...../edit

to

https://drive.google.com/..../preview

You can just use my script verbatim, no changes or env variables needed.

I think what you’re saying is you want to store the files in Google Drive and reference them locally? In that case, just use a normal local link and ignore my post above.

I don’t want to use web links, since I may want to include files which I sync locally on a Linux Server. With your approach I would need to always create a web link.
Let’s assume I got my Vault on two machines. On Machine A the file I want to include would be located at /home/user1/Drive/my/path/file. On Machine B the same file would be located at /Users/home/myfolder/my/path/file.
To include it in Obsidian I would need to create an environment variable which is obsidian_env= /home/user1/Drive/ on machine A and /Users/home/myfolder/ on machine B. Otherwise I would need to update the entries manually on each machine. Do you know how to do this or do you got a better way of doing it?

Just use relative paths - no need to use absolute paths. This isn’t really a Google Drive question, this is just normally linking files into your vault.

I can only use relative paths if its possible. If the file is not inside my vault I can’t link to it.

If you’re using Linux, why not just symlink the folder into the same .gitignore’d relative location on both machines, and then use relative paths?

This doesn’t really address your issue if you are intent on using Github… but have you thought of using Gitea or some other self-hosted docker Git instance? It solves the issue of storage, attachments, and your data is (or can be at least) stored locally.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.