Recommend blob-less Git clone

[Rudxain]

https://github.blog/open-source/git/get-up-to-speed-with-partial-clone-and-shallow-clone

Additionally, this PR changes bash Markdown code-blocks to sh, which is shorter and more neutral

[vercel]

@Rudxain is attempting to deploy a commit to the nyakofox's projects Team on Vercel.

A member of the Team first needs to authorize it.

[NyakoFox]

Let me get this straight -- I assume this reduces the resulting clone's size and only fetches blobs (which are like, file contents) when needed?

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
shadow	Ready	Preview	Comment	Sep 27, 2025 4:22pm

[Rudxain]

this reduces the resulting clone's size and only fetches blobs (which are like, file contents) when needed?

Exactly. It's like lazy-load for Git!

I was about to suggest shallow-clone instead of partial-clone, but that's a bad idea for general-purpose use; blob-less is a more sensible balance.

However, there are some pitfalls (which will be fixed by the Git team in the future).

See also

[NyakoFox]

I do want to make sure that contribution is as easy as possible for people -- will this affect the normal workflow in any way?

Ex. I always make people rebase (as to not create merge commits), and things like that. Will they still be able to use git how they normally do, I guess is what I'm asking.

[Rudxain]

will this affect the normal workflow in any way?

From what I've read, all Git commands have been "taught" to deal with missing blobs, and a few have full "awareness" of filters. The slowness issues happen because not all cmds are fully aware (yet). But they work the same way.

Ex. I always make people rebase (as to not create merge commits), and things like that. Will they still be able to use git how they normally do, I guess is what I'm asking.

From my experience, most rebase operations are just as fast, especially if the diff between branches is just 1 commit that changes a few files. I've only had slowness issues when there were hundreds of commits adding/modifying hundreds of files (which is the case for this repo)

[NyakoFox]

I don't really care about speed honestly, mostly worried about getting into weird states or having to do things differently to work with a partial clone.

[Rudxain]

In that case, the only concern should be backfill which is "experimental". Not sure if they mean the API or the implementation. But it's ran manually

[NyakoFox]

Well, what does it do? Again like, if we recommend this, I don't want anything to change for the end users other than saving on storage space... when would they need to run backfill?

Saying this because I've never used this myself, and I would like to prevent people asking for even more git help than what already happens...

[Rudxain]

Well, what does it do? [...] when would they need to run backfill?

The links I added answer both questions. TLDR:

• converts partial to full: entire repo, or 1 path (file or dir). Future fetches will still be partial (can be disabled by removing 1 line from .git/config)
• not needed, but speeds-up blame, which I expect most newbies wouldn't use anyway

I don't want anything to change for the end users other than saving on storage space
[...]
I would like to prevent people asking for even more git help than what already happens...

As a maintainer of UAD, I understand your concerns 😅. What if I revert the commit and instead just add links to the blog-post and the pitfalls, so that "advanced" users decide for themselves?

That way the cmd is still discoverable, but not officially recommended

[NyakoFox]

The links I added answer both questions.

Sorry, I have a hard time absorbing all of this honestly.

What if I revert the commit and instead just add links to the blog-post and the pitfalls, so that "advanced" users decide for themselves?

I WOULD like to recommend it, if it doesn't cause any problems, but I need to be sure that it doesn't. Maybe for now we can leave it out entirely and revisit this later? "Advanced" users probably know their way around git anyways, so if they know what a partial clone is, they shouldn't need us to tell them that.

[Rudxain]

Sorry, I have a hard time absorbing all of this honestly.

Yes it's a lot of info to digest 😅

I WOULD like to recommend it, if it doesn't cause any problems, but I need to be sure that it doesn't. Maybe for now we can leave it out entirely and revisit this later? "Advanced" users probably know their way around git anyways, so if they know what a partial clone is, they shouldn't need us to tell them that.

Fair enough. I've only been using this for a month. And I couldn't find more info about all the trade-offs.

I forgot to mention there are no missing files after cloning. I might have implied the repo-folder is empty, but it has all the files! So there's no immediate change in workflow. This is possible because checkout auto-downloads all the blobs needed to recreate any given commit