Merge multiple heads

[czarkoff]

This PR adds an ability to merge multiple heads. The operation can be started either from the commit view or from the branch list (second commit). As such merges often cannot be carried out automatically, the user is allowed to choose to use "ours" strategy for the merge, which allows to record a merge and lets user to continue (which would typically include cherry-picking needed commits manually and squashing them into the merge commit).

[love-linger]

I'm sorry. This is not the recommanded way to merge branches in SourceGit. In fact, supporting merging multiple branches doesn't simplify things, as it's more prone to conflicts.

Of the other software I have used, very few offer this functionality.

[czarkoff]

The point of this PR was not to simplify merges, but rather to allow performing multi-parent merges. Currently SourceGit user would have to perform those in terminal with a bit of additional effort of copy-pasting the branch names and/or commit IDs. That said, I understand that you might not be willing to provide and support UI for every git feature out there, so if this feature is not wanted, please go ahead and close this PR.

[love-linger]

I understand that some users like to use this way to merge multiple branches/commits at once. However, in this software, I do not recommend this. Because this action can be broken down into merging just one branch and doing it multiple times. This makes it easier to resolve conflicts or understand the entire commit history.

[love-linger]

Anthor reason that why I do not want to introduce this feature is that in most cases, the functions of different branches need to be merged into the main branch after the test of it has completed without issues, and merging multiple branches at once then test may make it difficult to findout which branch introduced the new issue.

[love-linger]

In my current working project, merging multiple branches at once is prohibited. Committers need to ensure the branch, which they want to merge into main branche, includes all necessary changes. And if necessary, they need to use commands such as squash/rebase to reorganize their commits before submitting the merge request. It is convenient for automated scripts to pull and test.

[czarkoff]

We used to have 2 cases when we did multiple parent merges:

1. When we made "hotfix releases," that is, backported changes from the feature branches to the old stable branches. This practice was eventually abandoned for multiple reasons including the complexity of such merges.
2. We maintain "deployment" branches - the branches where we merge the feature branches that are supposed to be deployed together to the testing servers. When some of the branches are then merged to the development head, we "rebase" the "deployment" branches by resetting the branch to the latest development HEAD and merging all non-merged feature branches. As our tree tends to have dozens of non-merged feature branches, merging these one-by-one produces a bit too much noise. Thus we attempt a multi-parent merge, and if that fails (more often then not), we do an "ours" merge with consequent cherry-pick of all commits from all those branches and squashing of all of that into a single merge commit.

[love-linger]

All right, you've convinced me.

I've merge this PR into develop branch, and add some changes to it. You can see commit 94daa46 for detail informations.

[czarkoff]

Thank you!