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?

I have now uploaded 20.2 preview build 16021 which comes with following subtree-related features:

SG-9149: Branches: distinguish between allowed and not allowed cross-subtree commands

SG-9149: Journal: distinguish between allowed and not allowed cross-subtree commands

SG-9149: Log: distinguish between allowed and not allowed cross-subtree commands

SG-9149: Cherry-Pick honors subtrees

SG-13690: Subtree: reset command

SG-13685: Subtree: "subtree split" command

SG-13686: Subtree: "subtree merge" command

SG-13693: Subtree: denote subtree refs in Log Graph, Journal and Branches view

Note that most of the functionality requires that a subtree had been initialized with "git subtree add", in order to have meta data present in the initial subtree merge commit message, like:

git-subtree-dir: src/project
git-subtree-mainline: e7f09673067cd094778ed6089c8d4fe0756e73ca
git-subtree-split: 4dffc803a8f86d75d64c26fa5836c240048c9ebb

The display of subtrees is kept really simple, by just denoting subtree Branches and Log Graph commits by ♣. This is very close to Git's core subtree design and should be sufficient for most users of a subtree-enabled repository which shouldn't be interested in the presence of subtrees at all. The only visual difference for them will be ♣ symbols for subtree-merges in the Log Graph. We could even hide them by default as long as there is no .git/subtree-cache folder present. Still, subtree-related logic, like merging or cherry-picking from subtrees, will work.

Those (few?) users which actually work with subtrees can add the corresponding subtree repository as additional remote and thus will get more subtree-related functionality in the Branches view.

The problem with a dedicated "Subtrees"-category (like "Features" or "Local Branches") is that it's orthogonal to SmartGit's current local-remote-branch categorization and would raise several questions.

IMHO, for core subtree operations, there is now just "git subtree add" missing. I'm wondering how the GUI could look like here:

- Should it be a simple operation which can be executed on any selected branch to add it as subtree, like Subtree Merge?

- Should it be more like the Submodule Add wizard?

Right, currently there is only a Simplified Chinese translation.