Copy SHA via Ctrl+C broken in 3.0 RC1

[drewnoakes]

Do you want to request a feature or report a bug?

Bug.

What is the current behavior?

Ctrl+C copies junk, or (worse) the SHA of a wrong commit!

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

1. Start GE fresh.
2. Select a commit.
3. Press Ctrl+C
4. The clipboard is filled with something like:

  | Hide submodule toolbar button when not needed |   | Drew Noakes | 2 days ago |   | -- | -- | -- | -- | -- | -- | --

5. Right click the commit and open the "Copy" submenu (don't click any menu items)
6. Click away then select a different commit
7. Ctrl+C
8. Clipboard will contain the SHA-1 of the wrong commit

Specifically, Ctrl+C copies the SHA-1 of the commit for which the context menu's copy submenu was last opened.

What is the expected behavior?

Ctrl+C always copies the SHA-1 of the selected commit.

Environment you encounter the issue:

• Git Extensions 3.00.00.02-rc1
• 7990325 (Dirty)
• Git 2.19.1.windows.1
• Microsoft Windows NT 10.0.17134.0
• .NET Framework 4.7.3190.0

Did this work in previous version of GitExtensions (which)?

Yes.

[drewnoakes]

I see this as a blocker for 3.0, given the dangerous behaviour of copying wrong data.

[spdr870]

This is some serious strange behavior.

[spdr870]

Did a quick fix. Not the best, but I have no time to look into in further. Was curious about what could cause such weird behaviour. Seems that when opening the contextmenu, a new ctrl-c howkey was registered, overwriting the existing one. I deleted that hotkey in the PR. Maybe someone has a better suggesting. What is the point for adding such a hotkey, after someone opened the contextmenu with the mouse?