this post was submitted on 25 Apr 2024
680 points (97.4% liked)

Programmer Humor

19564 readers
946 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 5 points 6 months ago* (last edited 6 months ago) (1 children)

What are you smoking? Shallow clones don't modify commit hashes.

The only thing that you lose is history, but that usually isn't a big deal.

--filter=blob:none probably also won't help too much here since the problem with node_modules is more about millions of individual files rather than large files (although both can be annoying).

[–] [email protected] 1 points 6 months ago (1 children)

From github's blog:

git clone --depth=1 <url> creates a shallow clone. These clones truncate the commit history to reduce the clone size. This creates some unexpected behavior issues, limiting which Git commands are possible. These clones also put undue stress on later fetches, so they are strongly discouraged for developer use. They are helpful for some build environments where the repository will be deleted after a single build.

Maybe the hashes aren't different, but the important part is that comparisons beyond the fetched depth don't work: git can't know if a shallowly cloned repo has a common ancestor with some given commit outside the range, e.g. a tag.

Blobless clones don't have that limitation. Git will download a hash+path for each file, but it won't download the contents, so it still takes much less space and time.

If you want to skip all file data without any limitations, you can do git clone --filter=tree:0 which doesn't even download the metadata

[–] [email protected] 2 points 6 months ago (1 children)

Yes, if you ask about a tag on a commit that you don't have git won't know about it. You would need to download that history. You also can't in general say "commit A doesn't contain commit B" as you don't know all of the parents.

You are completely right that --depth=1 will omit some data. That is sort of the point but it does have some downsides. Filters also omit some data but often the data will be fetched on demand which can be useful. (But will also cause other issues like blame taking ridiculous amounts of time.)

Neither option is wrong, they just have different tradeoffs.

[–] [email protected] 1 points 6 months ago

But that's my point: instead of things weirdly not working, they will work instead.