Your comments
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".
Because "File Name" and "Content" are so expensive, they are reset. Otherwise it may happen too easily that you forget about this option being set (it's more obvious now, but not too obvious, especially not for new users), invoke for a filter and wait much longer than necessary to get your results. Assumption here is that filtering for the file name (and especially content) is a rare event. I think for "File Name" we could a Low-Level Property to persist, though.
> - Remote > Subtree > Merge / Split / Reset are never clickable, whichever commit or branch I select
They will only be applicable if a commit belonging to a subtree has been selected, i.e. a commit denoted by ♣ or any of its ancestors. Why? All these commands require a prefix which is uniquely defined through the selected commit. Also, some of these commands require an additional ref, e.g. Split. Hence, the easiest way is to invoke Split from the context-menu for a ref in the Log Graph.
> - Previously, subtree merges would result in commit messages e.g. Merge remote-tracking branch 'sync-script/master' into staging, now they read Merge commit 'c73651ff26e1ba8f3d2629666a3be81e423ba454' into staging, which is useless
As you can see in the Output view, SmartGit is now executing something like:
$ git subtree merge --prefix=sub refs/remotes/subtree/master
It seems this command does not preserve the ref name. I agree that it should, but this is rather a shortcoming of "git subtree" itself.
> - On proper subtrees, the ♣ shows up only on the subtree commit right before a subtree merge, not on the merge itself.
Right, this is intended. It could show up on the subtree merge instead, but we want to denote subtree heads which are not yes merged and using ♣ for main repository sub-tree merges and actual subtree commits is slightly inconsistent. To me it's more reasonable that you can rely on ♣ to always point to a subtree commit.
> - https://github.com/roots/trellis never had subtrees, but certain branches still show ♣
Where can you see the ♣? I can only see ⚷ symbols which denote signed commits.
> - repositories that once were subtrees and are now living alone are still recognized as subtrees, which make Smartgit refuse to merge into root…
Can you please provide a test repository illustrating the problem?
Customer support service by UserEcho
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.