Make opening git difftool more consistent

[part22]

The default shortcut to open git difftool (ctrl+t) is not available on the "Local Branches" window. It is available when selecting a commit from a local branch, a remote branch, or a tag from the "Local Branches" window.

This is inconsistent since branches or tags are also commits, the shortcut should also work on them directly.

This commit remedies this inconsistency by allowing the use of the shortcut directly on a branch or a tag. The shortcut works both in the "standard" mode and the "diffing" mode.

Current Behaviour	New Behaviour
Select a branch Press enter to see the commits Select the head commit Press ctrl+t to open git difftool	Select a branch Press ctrl+t to open git difftool

• [x] Cheatsheets are up-to-date (run go generate ./...)
• [x] Code has been formatted (see here)
• [x] Tests have been added/updated (see here for the integration test guide)
• [x] Text is internationalised (see here)
• [ ] Docs have been updated if necessary
• [x] You've read through your own file changes for silly mistakes etc

[stefanhaller]

I'm not convinced that this behavior makes sense when not in diffing mode. In diffing mode it works as expected, opening difftool with the same diff that I'm seeing in the main window, which is a nice addition.

But outside of diffing mode it opens difftool with the diff of the last commit of the selected branch or tag, which doesn't make sense to me. What do users expect to see in this case? I can see two possibilities:

• "the diff of this branch". This could mean the diff of the commit range of the yellow commits of the branch, or in other words the diff of the branch head against the merge base with the closest main branch. The downside is that it only makes sense for branches, not for tags.
• "the diff of where I am compared to the branch". This is what you get when typing git difftool <somebranch> on the command line: it gives you the diff of the working tree against that branch.

I suppose I would prefer either the second of the options above (calling difftool with only one argument), or disabling the command when not in diffing mode.

Curious about your thoughts on this.

[part22]

Hi Stefan,

I think you are right, it is more consistent to have the same behaviour as the command line. We should chose the solution that will be the least surprising to git users.

I have modfied the behaviour so it matches the behaviour of git difftool <somebranch>.

Thanks for your feedback!

[stefanhaller]

Great work, thanks for bearing with my nitpicking. Looks very good now, merging.