The preview is not yet public. In the Graph context menu, there will be "Check Out" which is also the default action (i.e. will be invoked on double-click). This will make it easy to create temp branches.

There are some experimental Low-Level Properties for further streamlining (if you are using them, please drop us a note on how they work for you):

standard.checkout.commit.autoCreateTempBranch

standard.checkout.commit.autoDeleteTempBranch

Implemented for 23.1 preview 1.

You may set Preferences, Low-Level Property "standard.ui.layoutActions" to "true". This will give you Window|Set Layout {1|2} actions. These are orthogonal to Local Files/History, though. So, very similar to Window|{Main|Review} Perspective.

Also, note that this Low-Level Property is subject to change (it's even quite likely).

Second problem split off to https://smartgit.userecho.com/communities/1/topics/1500-

First problem: by default, SmartGit tries to build a graph of the filtered commits. This requires to look-ahead. Is responsiveness better when unselecting "Show Graph While Filtering"?

Currently, we don't have plans to implement this feature: until now, this workflow seems rather rare among (our Smart)Git users. On the other hand, this would require huge changes to SmartGit's code and overall architecture: SmartGit is doing lots of low-level access using internal Git libraries. This gives us better performance and more flexibility in implementing certain features. Introducing a client-server architecture in the core Git layer will most likely result in performance drawbacks for purely local users, or it would require to maintain two different implementations of certain algorithms which would make the change even more huge.

Other (popular) Git clients which do all the Git-related work exclusively by the git-executable can be adopted to this workflow much easier: run "ssh ... git <command>" instead of just "git <command>". But these clients usually suffer from worse overall performance or significant inflexibility, because where SmartGit will read a few bytes from a memory-mapped file, they have to invoke a new Git process to run a heavy-weight Git command.

I'm also not sure whether SmartGit is the right place to implement this client-server architecture: when generalizing this request, it would mean that every Git client would have to be changed to a similar client-server architecture. The remote machines would have to support the various server-side components to which the clients can then connect (as mentioned above, a "git" executable is not sufficient for SmartGit). To me this sounds more like the request for some new standard for a "Git server protocol", similar to the Language Server protocol, which would provide a low-level remote access onto the Git database. Hence, it could make sense to bring this entire topic to the attention of the Git community.

Concluding, it will be interesting to see into which direction the Software industry is developing. If this will become the prevailing workflow, we will have to swallow this bitter pill and implement it, too. But SmartGit will not be a first mover with respect to this topic (for the reasons outlined above).

Present in build 19196.

What exactly do you mean by "add a remote branch"? Do you mean to add a "remote" entry in the .git/config? With build 19196 there is now Remote|Add: Help|Check for Latest Build

Please give 22.1 Preview a try, here branch filtering has been implemented in the Standard window:

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

https://www.syntevo.com/smartgit/standard-window/

State was reverted by accident.