[Sorry, still figuring out the forum. Reposted as a "reply" as it should be.]

> The fetch will be triggered exactly once the Changes view tries to access blob data... which is triggered by the Graph selection.

Ah, just tried - I see what you mean. I think I was thinking of the 20.2 Preview 1 feature that allows the Changes view to auto-hide behind the Graph view and come to the front only when a file is selected. With that enabled, I think it would be good to not fetch until the Changes view is brought into focus (ie, by a Files view selection or by manually clicking the Changes tab).

This allows quickly perusing the Log for details other than the diffs (eg, parent/child commits, detailed commit message, etc), but still smoothly seeing diffs when needed. Do you agree?

> I would not fetch the entire commit but instead just fetch the missing blobs (git fetch ... <blobid>)

Even better if you can do that. I think you would want to fetch all blobs relating to that commit though (ie, all changed files in that commit) rather than just for the selected file. Reason being that this would allow the Compare view to track content that moves across files (SG-12887).

> Fetching these blobs should happen automatically, at least up to a certain size: if the user clicks through the Graph and investigates changes for certain commits, this should work smoothly

Agree with making things work smoothly! I think don't fetch when just clicking in the Log (because as a user I might just want to see what files changed, not the actual diffs), but if performance is good enough, then agree with automatic fetching when selecting files for comparison. (But if auto fetching makes things unresponsive, then this will be the opposite of a smooth experience! So I guess just need to play around and see...)

Fantastic! Really glad to see SmartGit thinking about "partial clone" support - I think once partial cloning matures and becomes generally available (along with sparse-checkout), this will really shake up the industry.

I was actually playing around with this the other day (with self-hosted Git 2.28), and the current situation with SmartGit and partial cloning isn't too bad:

1. If a blob is missing (eg, due to cloning with --filter=blob:none), the Changes view will currently display an error message. All we have to do is do a "checkout" of the relevant commit (from the GUI) and git will fetch the relevant blobs and then SmartGit will display the diff properly (the checkout will respect any sparse-checkout filters you've set up, so it's not too expensive).
   
   For new users who don't know this, I think a quick fix is simply for SmartGit to detect the error and replace it with a message allowing the user to fetch the commit blobs if they want to (please don't auto fetch when browsing through the Log though!). When the partial clone feature matures, it might also be possible to be more selective about what blobs to fetch. 
   
   
2. For repos that are large because of large binary files (and not because they have millions and millions of files and commits), cloning with something like --filter=blob:limit=1M seems to work ok (it only clones blobs smaller than 1MB, so all or most text diffs will be available, but it won't fetch large binaries until needed).

In future, as the partial clone path-based filter options mature, I think the ideal UI would be to have the left Repo pane be "expandable" to show files/folders in the repo (ls-tree not worktree). We could then use that Repo view to see what's available and change our partial clone filters / sparse checkout patterns without leaving the GUI (see https://smartgit.userecho.com/communities/1/topics/1150-sparse-checkout).

+1 (+100 if I could).

@Derrick, git checkout respects your current sparse filter patterns (at least it did when I tried with Git 2.28). You'll need to use the command line or manually edit the pattern file if you want to change the sparse filters - ie, to change the paths in your "work area" (or workspace as other VCS like to call it), but otherwise I don't think you need to leave the GUI?

What I'd really like to see though, is to be able to click a repo in the left pane Repo view and see the repo's file/folder tree (note that this would show all files/folders available in the repo - at HEAD maybe? - not just what's in the sparse worktree). The utility of this is that:

1. We can see what's in the repo vs our sparse workspace (similar to Perforce P4V's depot vs workspace view), possibly with a badge icon to indicate whether something is or isn't part of our sparse filter. 
   
   
2. We could right-click to add/remove files and folders from the patterns in the sparse-checkout file (ie, to add/remove paths from our "work area"). Similar logic to adding patterns to .gitignore, but would also need to handle "cone mode" patterns.
   
3. The Log graph could be filtered depending on our "work area" or which files/folders we have selected in the Repo view, so we can focus on just the history for the files we care about.

For performance, the Repo view would only need to show the repos at first, then selectively reveal files/folders when we expand a repo and its subfolders (currently already achievable from the command line using "git ls-tree").

Also, once Git's partial clone path-based filters mature a bit, the Repo view could possibly also be used to optionally change the partial clone filters at the same time (see https://smartgit.userecho.com/communities/1/topics/1223-partial-clone-support-git-219-and-higher-sg-13863).

This way, we'd be able to see and change the "shallow clone" depth, "partial clone" filter and "sparse checkout" patterns all in the same place without leaving the GUI. Gamechanger!