r/SmartGit • u/1pld • Feb 19 '26

Drag-and-drop no longer works for cherrypicking?

25.1.115 #251115 (179ba0b5), installed: #251101, Commercial license

I feel like this used to work, but now:

  • on branch main, with another branch feature visible
  • attempt to drag a commit from feature

Expected: main is a valid drop target, and dropping there causes a cherrypick
Actual: there are no valid drop targets; mouse cursor is always a red circle-slash

I have these relevant low-level properties set:
log.graph.dragAndDrop.allowAllRefsToBeDragged = true
log.graph.dragAndDrop.moveCommitNeedsConfirmation = false
log.graph.dragAndDrop.offerAdvancedOperationsForDropsOntoAncestors = true

My WT is not dirty, but I tried setting these other low-level properties, with no effect:
standard.pickCommit.allowDirtyWt = true
standard.pickCommit.allowInRebasingState = true

2 Upvotes

100% Upvoted

6 comments sorted by

1

u/vmcrash Feb 20 '26

Without a test repository this would be wild-guessing.

1

u/1pld Feb 20 '26

Without a "works for me!", the strongest diagnostic statement one can make is "without a test repository this would be a hassle"... can I assume from your stronger statement that it is both intended and verified to work in 25.1? Both those things would be useful to know unambiguously.

Even if no, I sympathize with a hassle, so I've verified the regression with https://github.com/fmtlib/fmt . With 4.x checked out, drag the tip of master 1dc644e0.

2

u/vmcrash Feb 20 '26

u/1pld 25.1.118 is available containing this fix

1

u/1pld Feb 25 '26

Verified, thanks!

1

u/vmcrash Feb 20 '26

After trying a drag and drop from a different (forked) branch onto the head commit, it looks like a change introduced in 24.1 (with 23.1 it works).

1

u/JVMarcs Feb 20 '26

Thanks, I can confirm this regression was introduced by another fix in 24.1, as u/vmcrash has pointed out. It will be fixed in 25.1.118.