feat: sync multiselect of branches and tags with commit list

[Danielku15]

See #2004

Old Behavior: If one branch is selected in the sidebar, the respective commit was selected in the commit list.

New Behavior: All selected branches or tags are synced to the commit list enabling branch diffing by selecting the branches in the sidebar.

Further details: To keep the change focused I didn't rework the sidebar further to also allow selecting tags and branches across the "groups" (e.g. selecting a tag and a branch). This could be a second extension.

I tried to follow the existing principles how the components and viewmodels already communicate between them. Architecturally the selection could be synced better via managing a central observable collection to which all components contribute their selections. But that's not how SourceGit currently works. I didn't want to rework too much but focus on the feature.

Not perfect, but definitely a improvement.

Demo:

SourceGit_u39iBWabEW.mp4

[love-linger]

I do not like this feature.

Since the RevisionCompare page does not show which revision is left or right side, and these selected branches/tags may point to the save revision, it is not really useful as expected.

For example, when selecting branch A, B, C (the HEAD of C and B points to the same revision/commit), the Revision Compare page shows two infos. But it not easy to find out which is A.

Here is the current approach of SourceGit:

• When comparing two revisions (selected commits in HISTORY page), it is easy to checkout which revision is left or right side.
• When choosing Compare with HEAD, there's a HEAD badge to show which side is HEAD commit.
• When choosing Compare with Worktree, there's a Worktree badage to show which side is Worktree.
• When choosing a branch to compare with current branch, the Branch Compare windows shows the position of these two branch.

[Danielku15]

I do not like this feature.

And I am heavily missing this feature after Moving from Fork and it fulfills exactly my needs. It's very cumbersome to manually search for the commits in the history to do a quick compare.

To that extend that if SourceGit doesn't add it, I'll start maintaining my own fork of SourceGit for that purpose. It is part of my daily workflow to do quick diffing between branches. It's a lot of time wasted searching things in the commit history manually.

Since the RevisionCompare page does not show which revision is left or right side, and these selected branches/tags may point to the save revision, it is not really useful as expected.

Not sure what you mean. The compare page shows which revision is left and right.
Diffing is only active if you select 2 separate items.

Just because there are exceptions and variants where the diffing does not activate, there is still the added value for the main use-case of diffing two different branches quickly.

For example, when selecting branch A, B, C (the HEAD of C and B points to the same revision/commit), the Revision Compare page shows two infos. But it not easy to find out which is A.

The problems you describe are not caused by my extension but are a general SourceGit issue. You get the exact same experience when you search the branches manually in the commit history and select them.

As described in the PR notes: SourceGit already selects the commit in the history when you select a branch. I simply extended it to support multi-select and this activates the existing feature.

If multiple branches point to the same commit, this one and only commit is selected in the history and no diffing activates. It's equal to select the one and only row in the commit history.

I did not add any custom logic to activate the revision compare in such cases.

[love-linger]

Since the RevisionCompare page does not show which revision is left or right side, and these selected branches/tags may point to the save revision, it is not really useful as expected.

Not sure what you mean. The compare page shows which revision is left and right.
Diffing is only active if you select 2 separate items.
The problems you describe are not caused by my extension but are a general SourceGit issue. You get the exact same experience when you search the branches manually in the commit history and select them.

What I mean is that when user manually choose two commits to compare, it is easy to find out which is on the left because the left is always the older one (until you swap them). But for branches, we can not find out the left/right commit is which one's HEAD.

As you have mentioned Fork, I downloaded it and tested this feature. For example, I've selected two branches and a tag, can you find out which two are compared in the following image, and which is the left one?

[love-linger]

In my opinion, the correct approach should be:

• When two refs are selected (whether they are branches or tags), a comparison must be triggered. If the HEADs of the two refs point to the same revision, a view should be displayed indicating that the two selected refs point to the same revision (commits).
• When more than two refs are selected, regardless of whether the actual revisions they point to are only two, the comparison view should not be displayed.
• In the refs' comparison view, the refs name badges should be displayed in commit's info

This way, users can form a consistent and easier-to-understand behavior, that is: selecting two refs allows them to be compared.

[love-linger]

I've pushed two new commits:

• Supports to compare selected tag with current HEAD
• Supports to compare selected 2 branches/tags

[Danielku15]

Sorry for the long post again. But I think to understand the general needs and my thinking behind my proposal it makes sense to explore things a bit deeper.

As you have mentioned Fork, I downloaded it and tested this feature. For example, I've selected two branches and a tag, can you find out which two are compared in the following image, and which is the left one?

IIRC fork goes one step further and remembers the selection order whereas in SourceGit defaults to "old left" (which I like more).

Looking it SourceGit it's indeed a bit more obvious when you start with the history as it is sorted chronologically, but as you might be reviewing the changes its still easy to get lost over time. To solve this confusion it would be a nice UX improvement to also show the branch/tag markers in the revision compare dialog (not only [HEAD]).

Personally I do not see a big end-user problem in identifying the "older and newer". As a user I start my selection with a certain knowledge on what I'm interested into:

• Checking my feature branch against main/develop I am less interested in the chronological aspect but rather content-wise what is the overall change looking like.
• Comparing two releases against each other I chose the respectively named branches knowing which one is newer and which one is older.

Things like that. Eventually I anyhow see details of the chronological relation and graph evolution in the history view thanks to the selection. Having additional badges in the revision view would clear out potential risks of confusion. Next level UX could be to have the current selection also highighted in the scrollbar (similar to how browser handle it when searching)

With this approach a lot of individual simple-to-maintain single-purpose features fulfill their own purpose and allow users to build complex workflows.

I've pushed two new commits:

Thanks for the additions. While it serves a certain need, I personally do not like the context menu approach from a UX perspective. Now there are multiple solutions to the same problem in SourceGit and there are more workflows which are not covered by this.

If we multi-select the commits in the history I have a clear reference where in the history we are. I can then, still continue to move the selection from that starting point checking how things evolved.

That's what the current "multi-select in history" approach covers nicely. The existing features are:

1. Selecting a single item in the sidebar, selects the respective commit in the history. This serves use-cases of identifying respective commits in the overall commit graph and their timely relation. From this initial selection users can further "browse" the history and take action.
2. Selecting two items in the history trigger the revision compare. This serves the use-case of comparing changes against each other. From this selection users might dig deeper into how changes evolved by changing the selections. Also other features like "Save as patch" (history context menu) can be then used from this state.

The new principle I'm recommending is:

1. Selecting multiple items in the sidebar should select all respective items in the history. This simple addition allows new combinations of the use-cases above. You can easily identify the historical relation between items through the history view. For 2 selected items you can see the diff and can drill-in further or use "Save as patch". You get the possibility to update selections through both commit graphs and the sidebar to explore your history and changes.

Your addition, while valuable, "just" targets a single specific use-case at the cost of maintaining multiple solutions to the same problem. Looking at potential feature evolutions where we want to compare tags and branches, they all will need dedicated implementations while my proposal would only need to allow keeping selections across the separate sidebar blocks.

IMO it is more sustainable to think how a combination of existing features can enable a workflow.

[love-linger]

I've totally rewrited the ref comparison ways. And now the RevisionCompare page only used for comparing selected commit with HEAD/worktree or comparing selected two revisions.

For ref comparison, a Compare window will always be used. And now user can compare selected branch/tag to any other branch/tag (not only HEAD) or compare selected two branches/tags.