3 ms·

Git isn't that bad at handling binary blobs - as long as you enable LFS support, and your git repo is served locally, as suggested, you'll do fine.

oefrha 7y ago
> as long as you enable LFS support You still end up with two copies of the same file, one in the local LFS “server”, one in the work tree, no? (I only played with LFS a bit many years ago when it first came out, so I could be wrong.) Unless you take into account deduplication built into certain filesystems.
- fit2rule 7y ago
  You don't get copies until you need them - thats the point entirely. More details here: https://www.atlassian.com/git/tutorials/git-lfs https://www.atlassian.com/git/tutorials/git-lfs Also saves you from beating up your index with every change. I've been using GIT LFS for the last 6 months with an Unreal Engine project, with multiple gigabytes of files being tracked, and it really is painless.
  - oefrha 7y ago
    > You don't get copies until you need them I know. But you do need them, and files in your work tree don’t magically disappear when you commit them in (presumably). So either you delete the work tree copy immediately after pushing it to LFS server, and duplicate the server copy every time you need to access it, in which case the file is only duplicated then but comes with elevated cost of access, or the latest copy sits around costing double the amount of space at all times.
    - Hello71 7y ago
      or just use a bare repo?
    - fit2rule 7y ago
      I don't see the issue? Either you want to use Git or not. I have gigabyte-scale files in my 6-month old repo's and haven't ever run into any issues. Of course this may be because my git server is right next to my desk and I'm on gigabit ethernet ..
hunter2_ 7y ago
Aside: are there non-binary and/or non-large blobs? I'm thinking along the lines of ATM machine / PIN number but maybe BLOB no longer implies "binary large" without being explicit.

oefrha 7y ago

> as long as you enable LFS support You still end up with two copies of the same file, one in the local LFS “server”, one in the work tree, no? (I only played with LFS a bit many years ago when it first came out, so I could be wrong.) Unless you take into account deduplication built into certain filesystems.

fit2rule 7y ago
You don't get copies until you need them - thats the point entirely. More details here: https://www.atlassian.com/git/tutorials/git-lfs https://www.atlassian.com/git/tutorials/git-lfs Also saves you from beating up your index with every change. I've been using GIT LFS for the last 6 months with an Unreal Engine project, with multiple gigabytes of files being tracked, and it really is painless.
- oefrha 7y ago
  > You don't get copies until you need them I know. But you do need them, and files in your work tree don’t magically disappear when you commit them in (presumably). So either you delete the work tree copy immediately after pushing it to LFS server, and duplicate the server copy every time you need to access it, in which case the file is only duplicated then but comes with elevated cost of access, or the latest copy sits around costing double the amount of space at all times.
  - Hello71 7y ago
    or just use a bare repo?
  - fit2rule 7y ago
    I don't see the issue? Either you want to use Git or not. I have gigabyte-scale files in my 6-month old repo's and haven't ever run into any issues. Of course this may be because my git server is right next to my desk and I'm on gigabit ethernet ..

hunter2_ 7y ago

Aside: are there non-binary and/or non-large blobs? I'm thinking along the lines of ATM machine / PIN number but maybe BLOB no longer implies "binary large" without being explicit.