Programmer Humor

19804 readers

647 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

Keep content in english
No advertisements
Posts must be related to programming or programmer topics

founded 2 years ago

MODERATORS

[email protected]

672

GOD DAMMIT STEVEN! NOT AGAIN! (lemmy.world)

submitted 7 months ago by Maven to c/[email protected]

72 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 7 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 7 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 7 months ago

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