To stay focussed on the current repository only.

When merging a branch which leads to conflicts, I often run into the problem that the conflicted files are spread across hundreds of rows in the Files view:

It is not practical at all to scroll though hundreds of files just to find the 5 conflicted files you need to resolve manually. The only practical option seems to be to sort the list by the State column, to have all conflicted files at the top.

That works fine, but after the merging state is left, the new sort order remains, and I have to change the sort order again to get the list sorted by relative directory & file name (i.e. a sorting order which feels comfortable for me).

As this is happening regularly, I'm constantly changing the sort order, which is annoying. I wish the sort order in the merging state is memorized separately from the sort order of the normal state. So every time I run into the merging state, files will be sorted by State automatically, and after leaving the merging state, sorting automatically changes back to Relative Directory & File Name (i.e. the sort order of *before* the merging state).

This would be a big quality of life improvement :-)

I often select to commits to see the differences between them. It would be great to have the path/commits between the selected highlighted.

Currently, the repositories can be grouped under custom groups, much like placing files into separate folders.

I would like to propose that you implement the same feature for local branches. Another variant could be to allow the tagging of branches. I don't mean the git tagging, I mean assigning custom labels to a branch and the providing a quick way to filter the branches by one or more selected tags. Either way works for me, but probably I would prefer the folder approach.

The reason for this is that I have lots of local branches that correspond to issues I've been working on throughout time. It becomes harder to figure out where some branches are at, especially when I have to switch context. I would like to
create a group called "Done" or "Implemented" and move the branches to this group after they are done to get rid of the visual clutter.

There were some previous suggestions on these lines under Branches view, though they are not exactly the same as my request.

When I open Conflict Solver, in numerous cases it overwhelms me with lots of unrelated changes because files were changed a lot. There may be only a few lines actually changed in the commit, but I see so many colorful lines showing the differences between ours/theirs and the merge result that it's difficult to understand what's going on without looking at the original commit. It's a confusing experience.

It would be great if all changes not relevant to the applied commit (as a result of cherry-picking, rebase, etc.) were somehow (optionally) highlighted. For example, irrelevant changes might be in muted colors.

Hi

in 25.x I used to see the gitlab merge requests in the log window

In 26.1 I cannot see them anymore

Have they been relocated?

Thanks in advance

In the header of the branches view, it would be cool if you could have a filter box for searching for branches. "Includes" string would be simplest, but could support regex too.

Often times I want to just see the log of a single branch or perhaps 2 branches. In this case it would be useful to right-click the first branch in the branches view and select that branch, and unselect all others.

Hi,

Recently I've found myself stumbling in this situation:

I was working on feature A.

While I was working on A, a new feature B was requested.
Being as B was heavily dependent on A's code I created feature B branch directly from A.

I've worked on both in parallel.
Since A was being tested at the time (which meant committing some bugfixes from time to time) I've kept merging it into B on a daily basis to keep B aligned and avoid conflicts in the future.

After a while I completed A which was then merged into master via Squash.
This is when I've found myself in a bit of a pickle.

Due to how squash works, merging master into B would now cause the same conflicts I thought I was avoiding by diligently keeping B aligned with A.

At this point I had 2 options:
1- solving conflicts in branch B AND keeping all commits from branch A.

2- create a 3rd branch C from Master and cherry-pick there all commits belonging specifically to branch B (in other words, ignoring all commits from branch A since all its changes were now in master albeit via the squash commit).

Now, the problem was that cherry-picking all intertwined commits from branch B was gonna be very tedious and error-prone. (they were a lot and mixed with A bugfixing commits)

From what I understand there are a combination of git commands to sort of achieve this result but of course I couldn't test it at work and had little time to test at home, hence my feature request here today (which I can confidently study and understand once implemented by git experts).