Your comments
This is quite an elaborate process (on both sides) and you users will still have to apply some configuration (OAuth ID + secret). For GitHub Enterprise, the easier path is using personal access tokens, as suggested at:
https://docs.syntevo.com/SmartGit/Latest/GitHub-Enterprise-Integration.html
In 24.1 Preview you can Deactivate multiple submodules at once.
> This work would be easier if commit graph would highlight the commits that affect a specific file.
> What I have in mind is workflow like this:
>
> 1. Select a file in Commit / Files dialog.
I'm not exactly sure what that means: I could imagine that the currently selected file from the Files view will always be used to highlight the commits (if the option has been selected in the hamburger menu).
To avoid performance problems, we'd limit this detection only to the commits of your feature branch. I.e. you will have to work insider a Git-Flow or Standard window "feature", to have this highlighting enabled. In addition, we might take into account all diverged commits between "main" and "origin/main". Otherwise, It's not reasonable to let SmartGit permanently scan over 100K "main" commits on every selection change.
I tried this myself now and -- to my own surprise -- once you change the commit selection in the Graph view, the logged file will be pre-selected *again*. This is even the case if the previously selected file is also present in the new commit. It's also the case when changing the selection from a single commit to two commits to diff those commits. Furthermore, the selection is revealed. This is contrary to the repository root Log, which will try to preserve the selected file. Either way, can you please give it a try yourself and confirm that the logged file is reliably selected?
23.1 Preview build 20116 will contain experimental Low-Level Properties "standard.actions.stageAll" and "standard.actions.unstageAll" to unlock such actions.
I also considered that, but the question is, what is Git's intended behavior? Is it the one defined in the documentation or the one actually present in the latest Git executable? It's likely that neither of them is perfect: the documentation might be outdated and the latest Git executable probably contains bugs. From the perspective of alternate Git implementations (such as SmartGit), the documentation is the better reference.
Your situation is not clear-cut because I don't think that the "root" username part of the Author email should always be replaced with "Vladimir Shulev". Therefore, it might be a good idea to bring this discrepancy to the attention of the Git community at https://git-scm.com/community.
Thanks, I can reproduce the problem. Following lines are not processed by SmartGit:
Vladimir Shulev <badfiles@mail.ru> badfiles Vladimir Shulev <badfiles@mail.ru> root
However, according to the mailmap format definition:
https://git-scm.com/docs/gitmailmap
such lines are actually unexpected. The correct line would be just:
Vladimir Shulev <badfiles@mail.ru>
or:
Vladimir Shulev 1 <badfiles@mail.ru> badfiles <badfiles@mail.ru> Vladimir Shulev 2 <badfiles@mail.ru> root <badfiles@mail.ru>
If you want to be more specific.
.mailmap should be supported since 22.1. Can you please give it a try and confirm? Then I'm going to close this topic.
You may find our videos series on "How to Clean Up Your History" interesting, especially:
Customer support service by UserEcho
SmartGit honors "init.defaultBranch":
https://git-scm.com/docs/git-config/#Documentation/git-config.txt-codeinitdefaultBranchcode