Perfect read for the project I'm working on, which uses git as an auditable backend storage! (The project is an open source multisig signoff solution: all multisig definitions and signatures collected are stored in a git repo you can clone, see https://asfaload.com/ )
I would guess that for at least 90% of the repos I clone, I just want to install something. Even for the rest, I might hack on the code but seldom look into the history. If I do then I could do a `git fetch` at that point and save the bandwidth and disk space the rest of the time.
This! The default was to have a link to download a tarball of the source. And if the user wanted to contribute (or check the devel version), you would add a link to the vcs.
I think gitignore solves a problem that is hard to solve with the traditional tarball approach.
Downloading a tarball and running ./configure or make, editing a config file here or there, etc then running `make install` is the most common flow. Now days I find myself frequently editing the Dockerfile to make it to my liking. With a git repo, the owners of the repo have excluded all the local files, build caches, etc and you can keep pulling to get updates stashing and reapplying your local changes. With tarballs, you have to figure it out all over again. Lose your build cache (language dependent maybe), lose a change you made here or there, etc.
Grabbing git repos instead of just tarballs is useful.
A) You can update them, because you can git pull to fetch changes.
B) If you want to apply patches on top, its better to have version control so you can keep track of what you changed, especially useful if you want to rebase.
Perfect read for the project I'm working on, which uses git as an auditable backend storage! (The project is an open source multisig signoff solution: all multisig definitions and signatures collected are stored in a git repo you can clone, see https://asfaload.com/ )
> LFS adds its own operational overhead.
Seemingly seconds on every remote-touching command, even on a very small repo.
ted nyman: #1 most knowledgable college football fan in sf
and also git
which makes more sense i guess
Of most things, really, he was on Jeopardy for a reason! https://thejeopardyfan.com/tag/ted-nyman
I've been wanting to ask this:
Why isn't
the default?I would guess that for at least 90% of the repos I clone, I just want to install something. Even for the rest, I might hack on the code but seldom look into the history. If I do then I could do a `git fetch` at that point and save the bandwidth and disk space the rest of the time.
try `git clone --filter=blob:none` instead
https://github.blog/open-source/git/get-up-to-speed-with-par...
https://gitperf.com/chapter-11.html
A question: why is git involved at all in this? You don't want a repository.
This! The default was to have a link to download a tarball of the source. And if the user wanted to contribute (or check the devel version), you would add a link to the vcs.
I think gitignore solves a problem that is hard to solve with the traditional tarball approach.
Downloading a tarball and running ./configure or make, editing a config file here or there, etc then running `make install` is the most common flow. Now days I find myself frequently editing the Dockerfile to make it to my liking. With a git repo, the owners of the repo have excluded all the local files, build caches, etc and you can keep pulling to get updates stashing and reapplying your local changes. With tarballs, you have to figure it out all over again. Lose your build cache (language dependent maybe), lose a change you made here or there, etc.
Grabbing git repos instead of just tarballs is useful.
A) You can update them, because you can git pull to fetch changes.
B) If you want to apply patches on top, its better to have version control so you can keep track of what you changed, especially useful if you want to rebase.
What if that's only you? Git isn't made only for those who "just want to install something"