For the Standard window, My History only shows pull requests that are relevant to you (as the Author/Assignee/Reviewer). There is currently no way to see all pull requests, and we are wondering whether a GUI client is actually the right place for this kind of overview. It's true that we have this feature in the Log window (but that doesn't necessarily mean it's ideal). Personally, when I need to manage pull requests, I switch to the GitHub Project instead (2 clicks in SmartGit) and continue there.

Here is a sample repository which uses "pdftotext". It should work out-of-the-box (tested on Windows):

textconv.zip

> A release branch would mark the start of the release process for a certain version and contain any changes on the way  to the actual release. When the release is done, the commit containing the sources for this version gets a tag with this version number and if there is a stable branch, it's fast-forwarded to this commit at the same time.

Is that close to what you are doing?

Exactly.

> 

The difficult part is merging those changes back into the development branch (since merging always has the potential to break things).

I think this could be separated from the release process, which means the release tag will always be on the last commit of the release branch. Any commit on the release branch might be merged into the development branch and in most cases the last one (containing all changes up to the release point) should be merged sooner or later to make sure you don't loose anything (but of course there might be exceptions to this rule).

That's also exactly what we are doing.

> I don't understand why tags are considered more "heavy-weight" than branches.

I have the following in mind: "main" represents the latest released/deployed version. And once you want to make a new deployment you simply move main a couple of commits forward. At certain milestones, when you make your deployment more public, you may in addition to that create a release-tag.

> Please feel free to rename this subject to attract more participants. It might help to get more input from other developers to see their needs.

I have done so now.

Thanks again for your detailed ideas!

Thanks for the details, and it's good to hear we're getting closer. Just a few more notes:

> One main branch that plays the roles of both main and develop branches.

You could also have an additional "stable" branch that represents the latest "deployed" state. This branch would simply fast-forward on develop but would not have any own commits (i.e. a real fork). This more or less a light-weight tracking, release tags would be more heavy-weight (see below).

> Releases are created directly from the main branch into itself, which means nothing more than creating a version tag.

If releases contain bug fixes themselves, these could be release branches instead (that's what we have).

Now I'm wondering whether we should rename the subject to "Standard Window: support releases." It's not entirely clear what this would do, but at least it may attract others to vote and comment here.

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.