When doing a complex merge using the conflict Solver I often use the Base Changes window to see what has changed between since the common parent in both cases which is a fantastic feature, thanks! When using the "Left+Base" mode the Base view still shows the changes compared to Right, even though it is hidden (and same when using Right+Base - the changes between Right and Base are still shown in the Base View).

Would it be possible to add an option (e.g. toolbar button or menu option) to toggle this behaviour to only show the diff between the relevant side and Base. This would then give the same effect as selecting the Base commit and whichever commit corresponds to Left or Right in the log window (which is the workaround I currently use).

Below is an example from an opensource project that (hopefully) illustrates what I mean.

Base Changes Window:

Base + Right selected

The changes shown for lines 45 to 56 in the Common Base above are the changes between Left and Base (which is what I would like to temporarily turn off). 

For reference, selecting the same two commits in the the log view and using the File Compare Tool shows the following:

And just in case you would also like to see it, this is the view for Left + Base:

and its associated File Compare (Base is on left in this view)

Hello,

I'm a junior dev with 2 years of professional experience and a SmartGit subscription.

While working on merge conflicts, I've noticed time after time that it would be immensely valuable to have a record of how each conflict was solved if just for some peace of mind and avoid finger pointing when a bug appears. The problem is that when a merge commit is created after resolving conflicts, Git doesn't keep track of several key pieces of info:

1- How many conflicts were there initially?
2- Which files were affected?
3- Which specific lines of a given file were in conflict?

4- How were the different conflicts solved?

Now, what's great about SmartGit is that when creating a merge commit a comment addressing point 2 is already being included. This is great! But I think we can do much better.

I have 3 propositions:

1- Generate a "Conflict Resolution Report: Upon creating the merge commit, it would be fantastic if SmartGit could export a detailed report for each conflicted file. A simple screenshot for each conflict could be a start/additional option.  A more useful text-based format like a .diff patch or an interactive HTML file, clearly highlighting what the conflict was and how it was solved would be even better since you never know what the user has on the screen during a screen capture. This would create an invaluable artifact for code reviews and future debugging. Even more powerful the ability to attach a comment to each change so that future me and other devs can quickly understand the reasoning behing complex decisions.

2- Record Resolution button: As an additional or alternative option, a "Record Resolution" button could be provided to trigger a video capture of the entire conflict resolution process, from the moment the user enters the Conflict Solver to the final save. This creates a high-fidelity audit trail and a last-resort backup of the decisions made. Even more, the trigger could set to be automatic. Every time I enter conflict resolver Smartgit would automatically trigger the recording. This way I don't always have to remember clicking the btn.

3- Built-in Conflict Recreation: Provide a way to "re-experience" a past merge conflict from the log. If a problem arises, I could select a merge commit, and SmartGit could instantly recreate the original conflict state in the Conflict Solver.

You could be the ones to implement all this, an entire system to audit each merge conflict.

On left-click in Graph window, the current commit is selected.

If user clicks on branch label, in addition, it would be great to select also this branch in Branches window.

Hi,

I have a feature proposal. Sometimes I do the following:

- type a filename in the "Files" tab and CTRL+L for seeing its history

- sometimes I search within the history

- I find the commit I'm interested in

- however now a really awkward set of actions is needed:

1. Copy the commit ID

2. Close the log window

3. Open the log window

4. Paste the commit ID to see surrounding commits and context

It would be great if there was a way to "step out" of the "local" (file based) log window and do a "reveal commit" globally, without closing and opening a new log window.

It would be desirable if the path to existing repositories could be adjusted in SmartGit.

Currently, this can only be done by removing and re-adding the respective repository or by manually editing the configuration files.

In my case, it was a necessary adjustment to the existing project structure that made this step necessary.

A helpful feature would be the ability to mark certain commits with a color, making them easier to find and revisit later.

Set an option to only show merge requests if user is Reviewer or Assigned to it.

As someone who thinks Conventional Commits is a noisy and useless convention (which the tagging should have been relegated to the body as a parsable format like `@type chore`), is it possible to allow a custom hook or script for users to pre-process the git log?  

The hook method also allows the user to do whatever they want (e.g. remove JIRA IDs), so I think it will be very flexible.  If usage becomes widespread, SmartGit can even promote some of these internally through a filter.

Performance might be an issue since it needs to be executed on every message, but since it is opt-in, it wouldn't affect 99% of users.

And just like any filtering, I guess there needs to be an indicator for when the filtering is in effect.

Hi,

When I want to merge my feature/fix branch to main branch I have always the check box "create simple commit (squash)" unchecked.

It will be usefull if there is a configuration to do to say :

• Check "create simple commit (squash)" by default when merge.
• Or check "create simple commit (squash)" by default when merge with a main branch (we can also assume that there is a configuration to identify a main branch list).

Thank you,

Karim