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

> 

> 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 agree, that sounds like an optimization which could even be done independently. I have logged this as SG-13950.

> > 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 movesacross files (SG-12887).

I agree, that sounds reasonable. Even without SG-12887, chances are good that if a user investigates a commit, he might check contents of other files of this commit as well. And as the "round trip" overhead of fetching a single blob is usually tremendous compared to the blob data itself, we should better fetch all blobs at once (given they are below a certain threshold).

> 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...)

The fetch will be triggered exactly once the Changes view tries to access blob data which in turn is triggered by the Files view selection which is triggered by the Graph selection. If you are working with partial clones and you are not interested in diffs at all, the best solution will be to close the Changes view in the Window|Main Perspective. This holds true already now if you want to prevent SmartGit from accessing Git-LFS blobs.

I think SmartGit would make sure that trees for all commits are present. Otherwise too much code might be affected by "missing objects" problems.

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).

I would not fetch the entire commit but instead just fetch the missing blobs (git fetch ... <blobid>). The blobs will only be required for the Changes view, so it will be only a few (or just a single one) out of every selected commit. 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.

SmartGit 20.2 preview build 16062 now also includes Remote - Subtree - Add. Also, the internal detection of subtree commits has been improved.

Regarding the dark mode problem, we are not aware of this. Can you please contact smartgit@syntevo.com with more details?

Please give 20.2 build 16058 a try. Get it from:

https://www.syntevo.com/smartgit/preview/

then invoke Help|Check for Latest Build.

Since a while you can configure Low-Level Property "github.pullRequestCommentPageLimit" which is now allowed to be "0".

You can configure "rebase.autostash":

https://git-scm.com/docs/git-rebase#Documentation/git-rebase.txt-rebaseautoStash

It works even better than SmartGit's own auto-stashing because it will be able to apply the stash even if rebase had been stopped and continued due to conflicts.

Duplicate of https://smartgit.userecho.com/communities/1/topics/681-

Resolved in DeepGit 4, SmartGit 20.1.

In 20.2 Preview, build 16041 there is now Low-Level Property "log.graph.filter.persistFileNameOption".