3 ms·

Honestly? Be a good customer. Help them help you and help yourself in the meanwhile Having a 1TB file sucks in way more ways than just "your backup provider do

Honestly? Be a good customer. Help them help you and help yourself in the meanwhile Having a 1TB file sucks in way more ways than just "your backup provider doesn't support it". Believe me.

davidt84 2y ago
Perhaps you could say something concrete, rather than vague waffle and assertions?
- 542354234235 2y ago
  Perhaps you could say something concrete, rather than vague criticism?
  - davidt84 2y ago
    What am I supposed to say in response to a comment conveying the message "be a good customer" with no further elaboration and the source "believe me"?
aleph_minus_one 2y ago
The problem is that it is often possible to solve the problem for (your) future, but you cannot get rid of the existing large files (if only for legacy reasons). One example: A Git repository that I created contained files that are above GitHub's file size limits. The reason was a bad design in my program. I could fix this design mistake, so that all files in the current revision of my Git repository are now "small". But I still cannot use GitHub because some old commit still contains these large files. So, I use(d) BitBucket instead of GitHub.
- Symbiote 2y ago
  You can rewrite the history of the repository to remove the huge files, if you wish. Of course, all the commit identifiers change.
  - aleph_minus_one 2y ago
    > You can rewrite the history of the repository to remove the huge files, if you wish. These old files nevertheless contain valuable data that I want to keep. Converting them to the new, much improved format would take serious efforts.
- znpy 2y ago
  On the other hand this means shifting responsibility to deal with past mistakes onto somebody else. Are you really sure you cannot rebase/edit/squash the commits in that git repositories? Yes, commit hashes will change, but will it actually be a problem?
  - aleph_minus_one 2y ago
    > On the other hand this means shifting responsibility to deal with past mistakes onto somebody else. This was just one example. Let me give another one: In some industries for audit reasons you have to keep lots of old data in case some auditor or regulator asks questions. In such a situation, the company cannot say "hey sorry, we changed our data format, so we cannot provide you the data that you asked for." - this will immediately get the company into legal trouble. Instead, while one is allowed to improve things, perfect capability to handle the old data has to be ensured.
- rschiavone 2y ago
  If the repository is personal one managed only by you, you can squash the commits so the large files disappear from the history. You can do that on shared repos too but that would cause a bad headache to other maintainers.

Honestly? Be a good customer. Help them help you and help yourself in the meanwhile Having a 1TB file sucks in way more ways than just "your backup provider doesn't support it". Believe me.

davidt84 2y ago

Perhaps you could say something concrete, rather than vague waffle and assertions?

542354234235 2y ago
Perhaps you could say something concrete, rather than vague criticism?
- davidt84 2y ago
  What am I supposed to say in response to a comment conveying the message "be a good customer" with no further elaboration and the source "believe me"?

aleph_minus_one 2y ago

The problem is that it is often possible to solve the problem for (your) future, but you cannot get rid of the existing large files (if only for legacy reasons). One example: A Git repository that I created contained files that are above GitHub's file size limits. The reason was a bad design in my program. I could fix this design mistake, so that all files in the current revision of my Git repository are now "small". But I still cannot use GitHub because some old commit still contains these large files. So, I use(d) BitBucket instead of GitHub.

Symbiote 2y ago
You can rewrite the history of the repository to remove the huge files, if you wish. Of course, all the commit identifiers change.
- aleph_minus_one 2y ago
  > You can rewrite the history of the repository to remove the huge files, if you wish. These old files nevertheless contain valuable data that I want to keep. Converting them to the new, much improved format would take serious efforts.
znpy 2y ago
On the other hand this means shifting responsibility to deal with past mistakes onto somebody else. Are you really sure you cannot rebase/edit/squash the commits in that git repositories? Yes, commit hashes will change, but will it actually be a problem?
- aleph_minus_one 2y ago
  > On the other hand this means shifting responsibility to deal with past mistakes onto somebody else. This was just one example. Let me give another one: In some industries for audit reasons you have to keep lots of old data in case some auditor or regulator asks questions. In such a situation, the company cannot say "hey sorry, we changed our data format, so we cannot provide you the data that you asked for." - this will immediately get the company into legal trouble. Instead, while one is allowed to improve things, perfect capability to handle the old data has to be ensured.
rschiavone 2y ago
If the repository is personal one managed only by you, you can squash the commits so the large files disappear from the history. You can do that on shared repos too but that would cause a bad headache to other maintainers.