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.
Thanks. That's great! I especially like that it then lazy loads the blobs as you need them.
I was going to ask if there's a way to set that as the default but I guess I'll just set up an alias like I have for most of the subcommands I use daily.
After that, once you do a sync or update, there's a whole lot more cloning going on.
The other projects I was going to mention have apparently all switched away from using git for their package management (homebrew, Go, cargo, ...). I can't help but wonder to what extent that might have been influenced by the default slowness of doing a full git clone?
Of course these all could add `--depth 1` to their instructions or internal package management tooling, and ofc we need both options to be available. I pondering aloud that in my observation, `--depth 1` is probably the option that I want more often than not but YMMV.
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.
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.
A) only valid if you want to stay with the devel version
B) See A
I use OpenBSD and before that, I was on alpine, debian, and arch. Of it was a software I want to try, I downloaded the tarball. if it’s something I wanted to keep for longer, I created a port or a custom packages.
> Otherwise you might as well include versioning for any other case.
It’s easier to version a port and the patches than to try keeping a series and patches on top of a dev branch. Not saying that your use cases are invalid, but the point of the thread was using git for building software. If you’re not developing the software, there’s no need to go from something that is working well to an unstable build every week.
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.
Fair enough. I also work with a monorepo at work but that I cloned like 5 years ago.
If I think about what I've cloned over the last week or so (LazyVim, gstack, my dotfiles), most of the time I just want the current state and be able to pull updates. Even for my dotfiles or projects that I fork and hack on, most of the time I'm just adding commits and it's seldom that I want to go back to historical ones.
Given how often I see `git clone ...` instructions in Github README.md files, I was just wondering how many other people felt the same?
So my contention is that most of the time, `git clone --depth 1` or `git clone --filter=blob:none` is what you actually want, and in the case that you want the full history then you could do `git clone --depth 0` (or `git clone -full` for even better UX, not that the git cli is known for it's UX).
Its not the default because that'd be counter-productive to developers who use git with larger repositories, which is how git started life in the first place - your clone depth would be entirely useless for Linux kernel developers, for example, if it were default ..
This is a good point and imo there is an interesting tension between adaptability and specialization.
Stable environments naturally drive populations towards more specialized actors in niches as they benefit from efficiency. Think of leverage in the financial economy or the dinosaurs.
When a big system disruption inevitably arrives, you better hope you still have some depth around with adaptable general populations that can survive the crisis and occupy the new environment. Think of Minsky moments and the K-Pg event for the dinosaurs 66 million years ago.
Another example would be stem cells vs organs and their specialized cell types.
It seems to me like you need enough regular change to avoid overspecialization and preserve the ability to survive large changes.
This is how future codebases will be analysed. Don't let perfect be the enemy of good. Evolution been doing Agile for aeons. Responding to change over following a plan ...
Ah; but how annoying it is to discover something like the inverted retina bug, only to figure out it is effectively unsolvable now due to all the follow-up architecture decisions built on it?
If you already have a version of GnuPG installed, you can simply
verify the supplied signature. For example to verify the signature
of the file gnupg-2.5.19.tar.bz2 you would use this command:
gpg --verify gnupg-2.5.19.tar.bz2.sig gnupg-2.5.19.tar.bz2
This checks whether the signature file matches the source file.
You should see a message indicating that the signature is good and
made by one or more of the release signing keys. Make sure that
this is a valid key, either by matching the shown fingerprint
against a trustworthy list of valid release signing keys or by
checking that the key has been signed by trustworthy other keys.
See the end of this mail for information on the signing keys.
* If you are not able to use an existing version of GnuPG, you have
to verify the SHA-1 checksum. On Unix systems the command to do
this is either "sha1sum" or "shasum". Assuming you downloaded the
file gnupg-2.5.19.tar.bz2, you run the command like this:
Another aspect which was too long for me to type on my phone earlier is that debt/Schuld is backward looking while liability/Pflicht is forward looking.
So while debt is incurred through past actions, what matters from an operational business perspective is your liability, i.e. your obligation for future payments/value transfers.
In english speaking business practice, debt and liability seemt to be used interchangeably. I have never used German in a professional setting and am only familiar with the colloquial usage of Schuld and Pflicht so I would be interested to hear how those differences play out in German business use.
In plural form "Schulden" is exclusively used for debt. The more common term for liability is "Haftung" which also translates to accountability (GmbH for an LLC means Gesellschaft mit beschraenkter Haftung). The singular "Schuld" can also mean guilt, blame or fault. But they are all pretty negative in their connotation.
The prevailing theory is that Anthropic doesn't have sufficient compute capacity to support Mythos at scale, which is the real reason it hasn't released.
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.
reply