4 ms·

My dream Git successor would use either dedupe or a simple cache plus copy-on-write so that repos can commit toolchains and dependencies and users wouldn’t need

My dream Git successor would use either dedupe or a simple cache plus copy-on-write so that repos can commit toolchains and dependencies and users wouldn’t need to worry about disk drive bloat. Maybe someday…

fragmede 2y ago
It does dedup using Sha-1 on entire files. you might try git-lfs for your usecase though.
- forrestthewoods 2y ago
  Git LFS is a really really bad gross hack. It’s awful. https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/ https://www.forrestthewoods.com/blog/dependencies-belong-in-...
  - fragmede 2y ago
    It's quite functional and usable, now. so I'd agree with hack, just not the rest of your adjectives. That was a good read! I've been thinking a lot about what comes after git too. One thing you don't address is that no one wants all parts at once either, not would it fit on one computer, so I should be able to checkout just one subdirectory of a repo.
    - forrestthewoods 2y ago
      > One thing you don't address is that no one wants all parts at once either, not would it fit on one computer, so I should be able to checkout just one subdirectory of a repo. That’s the problem that a virtual file system solves. When you clone a repo it only materializes files when they’re accessed. This is how my work repo operates. It’s great.
      - fragmede 2y ago
        The problem I'm trying to avoid is having to dive down a hierarchy, and that not everyone needs or wants to know there is such a hierarchy. Like graphics design for foo-team only needs to have access to some subset of graphics. Arguably they could be given a symlink into the checkout, but the problem with that is of having a singular checkout. The problem I had with Google3 is that the tools weren't great at branching and didn't fit my workflow, which tends to involve multiple checkouts (or worktrees using git). being forced to checkout the root of the repo, and then having to manage a symlink on top of that is no good for users that don't need/want to manage the complexity of having a single machine-global checkout.

fragmede 2y ago

It does dedup using Sha-1 on entire files. you might try git-lfs for your usecase though.

forrestthewoods 2y ago
Git LFS is a really really bad gross hack. It’s awful. https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/ https://www.forrestthewoods.com/blog/dependencies-belong-in-...
- fragmede 2y ago
  It's quite functional and usable, now. so I'd agree with hack, just not the rest of your adjectives. That was a good read! I've been thinking a lot about what comes after git too. One thing you don't address is that no one wants all parts at once either, not would it fit on one computer, so I should be able to checkout just one subdirectory of a repo.
  - forrestthewoods 2y ago
    > One thing you don't address is that no one wants all parts at once either, not would it fit on one computer, so I should be able to checkout just one subdirectory of a repo. That’s the problem that a virtual file system solves. When you clone a repo it only materializes files when they’re accessed. This is how my work repo operates. It’s great.
    - fragmede 2y ago
      The problem I'm trying to avoid is having to dive down a hierarchy, and that not everyone needs or wants to know there is such a hierarchy. Like graphics design for foo-team only needs to have access to some subset of graphics. Arguably they could be given a symlink into the checkout, but the problem with that is of having a singular checkout. The problem I had with Google3 is that the tools weren't great at branching and didn't fit my workflow, which tends to involve multiple checkouts (or worktrees using git). being forced to checkout the root of the repo, and then having to manage a symlink on top of that is no good for users that don't need/want to manage the complexity of having a single machine-global checkout.