I always use the newest version of Mercurial and sadly SmartGit/Hg doesn't support Mercurial 3.8

is there a reason why there has to be a supported version? it should be like git where it doesn't really care what version you have installed

Currently, the compare shows a left and a right pane so only up to the half of the screen width is used. Often to less for seeing the full line without scrolling horizontally.

Suggestion: (optionally) show a 2-line view below both, the left and right panes, that show the left focused line above the right focused line. That way you have a longer display and easier can spot differences.

WSLg can be used to run SmartGit in Linux environment while using Windows as main development OS.

We have tried it briefly and SmartGit seems to mostly work file in WSLg.

Out findings are summarized here:

https://docs.syntevo.com/SmartGit/HowTos/Running-on-WSLg.html

There are a few nuisances, such as SmartGit updates failing, which can be improved.

The current plan is to spend a couple days in the next couple months to try to fix nuisances.

However, if this proves to be complicated, we'll get back to more popular feature requests, unless this topic gains more votes.

If you're interested in using WSLg with SmartGit, please describe your use cases and any problems you encountered.

Note: this topic is about running SmartGit from within WSLg. If you want to access repositories on WSL from Windows, vote for topic 1409.

In the Git-Flow 'Finish Feature' dialog is should be possible to select ‘Create Pull Request..’ as well. 

Hi,

I use a lot GIT Rerere. It's really powerful when you have to deal with lots of conflicts (this depends on your GIT usage of course).

One of the most complicated point with this tool (in my opinion) is that you have very little visibility on available recorded resolutions.

That's why I think it would be very helpful in a GIT GUI like Smartgit to be able to see a list of recorded resolutions. Or maybe to highlight the fact that a conflict was auto-solved by GIT Rerere when it is the case.

An other hard part with GIT Rerere is to deal with wrong conflict resolutions. Once you recorded a wrong conflict resolution, it is hard to know how to revert this using the forget command.

I think a GUI tool showing where Rerere did its magic and allowing to undo this magic and forget the matching resolution would be just the perfect tool to make Rerere easy to use.

I'm sure there's other great things to do about GIT Rerere in a GUI, but there's so many interesting subjects....

I hope you'll have the opportunity to add this to Smartgit one day :) 

Thanks again for your great work

SmartGit 20.1 already denotes signed tags and commits (in the Branches view and Log graph) by black key symbols.

SmartGit should also verify these signatures (if possible) and denote:

- signature OK
- signature could not be verified (bad?)
- signature unknow

We have hundreds of branches in our project. They are created automatically for every issue and bug. When I need to find and clone specific branch, it is really hard to find them in the long list. There is search, but that is not very useful, because it only jumps to the first matching branch name. It would be really helpful to be able to filter the branches, to type part of the name and the view would only display matching branches.

Similar to Sourcetree, in the commit dialog I'd like to see which branch I'm committing and pushing to, to avoid committing to the wrong branch.

Please add an icon/modifier (similar to the green and red arrows) to a repo in the repository view if you are in a local branch that you have not pushed.  We often end up in a situation where a developer has created a release or feature branch but did not push it.  There is not obvious/quick way to spot local branches like you can spot uncommitted changes (red icons) or unpushed commits (red arrow).

Regularly, I fetch, pull, and push multiple repos via the multi-select repo feature.  SG sequentially executes the command for each repo.  Would it reduce the elapsed time for all by having SG execute them concurrently (or in batches, such as 5 repos at a time)?