I have implemented Git-Flow in the Log window and the new "Standard Flow" in the Standard window, so you can assume I know what I'm talking about and that there is a purpose to my questions.

As mentioned previously, the Standard Flow is derived from Git-Flow. Try it out: simulate concurrent changes to your main or feature branch in the remote repository, then hit Integrate and see what checks are made and which Git operations are triggered. It's fair to say that the Standard window doesn't employ Git-Flow and we essentially want to maintain it that way. However, that doesn't mean we won't improve the Standard Flow, which is optimized for a Git GUI (unlike Git-Flow). This is precisely the focus of my questions:

> Not having separate main and development branches sounds like "Light" mode. This is fine for some projects, but the "Full" mode provides better options to manage release builds.

How exactly are you using both branches? The develop branch is pretty obvious, but is this separate, single main branch really the perfect solution? And all this tightly defined release-branch logic... why not simply fork a release branch (or many, if there are multiple releases of your product) and merge them (possibly cascading)? What about all the tags which become created? Also, consider the "support" branches and "bugfix" branches which have been added after the initial version. Do we really have to distinguish between "hotfixes" and "bugfixes"?

As a side note, in his "Note of reflection" in the referenced Blog post, Vincent himself suggests re-evaluating his approach for your specific situation and considering GitHub Flow instead.

In the Standard window, we have implemented Features but this is not exactly Git-Flow. Supporting real Git-Flow side-by-side isn't feasible. Can you please explain in more detail what exactly you are missing in the Standard window?

Hotfixes? - What exactly is your workflow?

Differentiation between develop and main? - Why exactly do you need both?

...

SmartGit honors "init.defaultBranch":

https://git-scm.com/docs/git-config/#Documentation/git-config.txt-codeinitdefaultBranchcode

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.