61–70 of 142 posts
Earlier quoted context omitted.
For S3, that's $1.15 storage ($0.023/GB) + $4.50 transfer ($0.09/GB) so it's actually very comparable.
Yikes. Being comparable to amazon in price, purely because of how much amazon overcharges for bandwidth, is not exactly a flattering comparison. If you were to add the $1.15 storage cost onto a reasonable bandwidth number like $0.01/GB you'd just about reach a third of $5.
git-annex is an interesting alternative the HTTP-first nature of Git LFS and the one-way door bother you. You can remove it after the fact if you don't like it, it supports a ton of protocols, and it's distributed just like git is (you can share the files managed by git-annex among different repos or even among different non-git backends such as S3). The main issue that git-annex does not solve is that, like Git LFS,…
With git-annex you have the same "one-way door" behavior: it replaces large files with a pointer to the content (in git-annex, it's a relative symbolic link which by default encodes the real file's size and hash), which is stored in git-annex's own database.
The "one-way door" as I understand the article to be describing is talking about the additional layer of centralization that Git LFS brings. In particular it's pretty annoying to have to always spin up a full HTTPS server just to be able to have access to your files. There is now always a source of truth that is inconvenient to work around when you might still have the files lying around on a bunch of different hard drives or USB drives.
Whereas with git-annex, it is true that without rewriting history, even if you disable git-annex moving forward, you'll still have symlinks in your git history. However, as long as you still have your exact binary files sitting around somewhere, you can always import them back on the fly, so e.g. to move away from git-annex you can just commit the binary files directly to your git directory and then just copy them out to a separate folder whenever you go back to an old commit and re-import them.
But perhaps I'm interpreting the author incorrectly, in which case it's hard for me to see how any solution for large files in git would allow you to move back without rewriting history to an ordinary git repository without large file support.
Not to mention, many users are paying for a service that provides LFS, and hosting an LFS service isn't crazy hard. It's a file server with a custom API, it's mostly doable using S3 as a backend. It's not like this is crazy complicated stuff.
Earlier quoted context omitted.
$60 / year for a decent fraction of a hard disk and the associated backup resources, seems pretty fair to me. What price would you expect?
> $60 / year for a decent fraction of a hard disk and the associated backup resources, seems pretty fair to me. What you describe sounds fair to me. The problem is that 50GB is not a decent fraction of a hard disk.
I need the data for my team, so we pay, but I use it as an excuse to force the team to clean up data every so often. As a game company we need large repos. It was either Gitlab or Azure DevOps.
Earlier quoted context omitted.
The issue is breaking external references. Do you include git SHAs in your bug tracking system? Or perhaps your department wiki links to a specific commit to document lessons learned? Maybe you're using Sentry and find including the git SHA of the build to be invaluable for troubleshooting? For some organizations, rewriting history would be a non-event and for others it would be a major disruption.
Yeah, git is really not a mature or well-designed VCS. The fact that you can trivially lose the supposed permanent reference -- and that it's encouraged as part of several common workflows at that -- should be more than enough to demonstrate this. If you care about history, use a VCS like Fossil.
> Git on Windows client corrupts files > 4Gb
It's apparently an upstream issue with Git on Windows, but if you depend on something, you inherit its issues.
Earlier quoted context omitted.
> $60 / year for a decent fraction of a hard disk and the associated backup resources, seems pretty fair to me. What you describe sounds fair to me. The problem is that 50GB is not a decent fraction of a hard disk.
Just be thankful you are not on Gitlab. We pay $60/year for 10GB. I need the data for my team, so we pay, but I use it as an excuse to force the team to clean up data every so often. As a game company we need large repos. It was either Gitlab or Azure DevOps.
I get that a mercurial developer has different preferences but I don’t think that this is an especially effective form of advocacy.
Earlier quoted context omitted.
This looks too aggressive. The nice thing about git-lfs is that only the binary file type(s) you care about are run through git-lfs. All other ordinary diffable text is treated normally. The blobless clone is going to be ensaddening the next time that I'm examining the history of some source code when I'm hacking away without a network connection.
You can mitigate a bit of this by only ignoring blobs over a certain size like "--filter=blob:limit=256k" which should allow most ordinary text files through. In the end it's the same as LFS though in that without a network examining old commits without a network is a bummer. No free lunch here besides something a bit more complex like git-annex.
The gitattributes file provides a version-controlled and review-controlled mechanism to decide exactly which objects get special treatment and which ones don't. Since its a part of the repository itself, you don't have to remind new developers to specify some unusual arguments to git at clone time to avoid a performance disaster.
> In the end it's the same as LFS though in that without a network examining old commits without a network is a bummer.
Except for a crucial detail: The tools I use to examine history are the log, diff[tool], and blame. All of those tools continue to function normally on an LFS-enabled offline clone. IIUC, `--filter=blob:none` doesn't work at all, and `--filter=blob:limit=256k` is a proxy which almost, but doesn't quite work.
I despise LFS. I’m sure that if you know how to use it... maybe... you can figure it out. That said; here’s my battle story: Estimate the time it’ll take to move all our repositories from a to b they said. Us: with all branches? Them: just main and develop. Us: you just clone and push to the new origin, it’s not zero but it’s trivial. Weeks later... Yeah. LFS is now banned. LFS is not a distributed version control sy…