Id say it probably is.
For single user backing up, archiving, cloud access for binary files... yeh, sharepoint/onedrive probably IS better than git.
BUT, i say that with 0 experience of using either for that. I use git for text, and i havent had the "pleasure" of onedrive/sharepoint.
But i have a feeling that onedrive/sharepoint will have an edge over git as a cloud drive system. Even if its just from a tooling/integration standpoint
Large files is actually what git-lfs was made for. I haven’t used it extensively but the project has been around for quite a while (implying some measure of stability/userbase). I heard about it over ten years ago.
But your point still stands. GitHub isn’t the solution unless you have few files that you don’t mind being public (because I think GitHub has exposed private repos before).
Yeh, there are workarounds for large & binary files.
Git-LFS stores a pointer to the file that is stored elsewhere.
So... you have a git repo of files that point to somewhere that stores the actual files.
Great if your graphics/assets pipeline or whatever stores the files somewhere, and your codebase uses those assets.
Not great as the primary system to replace google/microsoft drive.
Might as well just have/use something that stores the actual files.
8 replies
This has to be a joke.
GitHub is owned by microsoft. So just use onedrive, a system actually designed for storing files.
Git is terrible for binary files and karge files. So even if you self host a git repo, you are probably going to have a bad time.
You say that like SharePoint is any better which OneDrive is a front end for.
Id say it probably is.
For single user backing up, archiving, cloud access for binary files... yeh, sharepoint/onedrive probably IS better than git.
BUT, i say that with 0 experience of using either for that. I use git for text, and i havent had the "pleasure" of onedrive/sharepoint.
But i have a feeling that onedrive/sharepoint will have an edge over git as a cloud drive system. Even if its just from a tooling/integration standpoint
Large files is actually what git-lfs was made for. I haven’t used it extensively but the project has been around for quite a while (implying some measure of stability/userbase). I heard about it over ten years ago.
But your point still stands. GitHub isn’t the solution unless you have few files that you don’t mind being public (because I think GitHub has exposed private repos before).
Yeh, there are workarounds for large & binary files.
Git-LFS stores a pointer to the file that is stored elsewhere.
So... you have a git repo of files that point to somewhere that stores the actual files.
Great if your graphics/assets pipeline or whatever stores the files somewhere, and your codebase uses those assets.
Not great as the primary system to replace google/microsoft drive.
Might as well just have/use something that stores the actual files.
Better yet, use an end-to-end encrypted service so that they can't use everything you store there as AI training material.
Github will call you if you hit 5GB in a repository, Google drive lets you have 15.
You'd have to write your own sync routines, and Github also has individual file size limits.
Or use gitfs. Yes, that really exists. Because of course it does.