Allow pasting (cherry picking) commits onto branch from branches view

[jesseduffield]

Is your feature request related to a problem? Please describe. Currently, in order to cherry-pick commits, you need to:

1. select the commits
2. checkout the destination branch
3. paste the commits by pressing 'v' in the local branches view

In github desktop you instead select select the commits and right click to cherry pick, then in a popup you specify the destination branch. That branch is then checked out (with any working tree changes stashed if required) and the commits are cherry picked. You then remain on the destination branch.

Describe the solution you'd like Given that we're not using the 'V' keybinding for anything else in the commits view, I think we should support pressing 'V' directly on the branch. This will:

• check if changes need to be stashed, and if so, prompt the user whether they want to stash the changes
• check out the branch
• paste the commits

We should also support this if you're in the sub-commits view, viewing the commits of a local branch.

This slightly reduces the amount of work required in cherry picking commits from one branch to another.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

[nhAnik]

Hi @jesseduffield , I would like to give it a try. Would you please assign me?

[jesseduffield]

Sure thing @nhAnik, let me know if you need any pointers.

For starters you'll want to add the keybinding to pkg/gui/controllers/branches_controller.go and internally you'll want to check out the (if it's not already checked out) and then call self.c.Helpers().CherryPick.Paste()

[nhAnik]

Thanks! Skimming through the codes and dev docs. I will ask you if I need any help.

[stefanhaller]

I wonder if the proposed UX is the best one for this feature. Personally I would find it somewhat unexpected that a branch is checked out automatically when I invoke this command.

With the new 2.44 version of git we could consider a different approach:

• check if the destination branch is checked out in any worktree, if so, switch to it (after prompting the user, probably) and proceed normally
• otherwise, use git replay --advance to cherry-pick the commits onto the destination branch without checking it out. See here for more information.

The downside is that we'd have to make a version-check and disable the command for git versions older than 2.44; also, the replay command is marked as experimental in the documentation, so I'm not sure we already want to rely on it.

Any thoughts @jesseduffield?

[jesseduffield]

I'm in favour for a feature for git replay that's marked as experimental in tandem with the underlying git feature.

[stefanhaller]

OK cool. @nhAnik I haven't looked at the code of #3288 at all to tell how much of it was done in vain. Sorry for not mentioning this earlier!

BTW, one downside of the git replay approach is that if there's a conflict, the command simply fails with an error code. The user will then have to check out the branch and try pasting there again to see what the conflicts are.

[RyanTalbot]

This sounds super interesting, I'd like to take a crack at it if @nhAnik isn't able to get around to it @jesseduffield.

[stefanhaller]

@RyanTalbot Have you seen #3288? There is an existing PR already, it just hasn't progressed for quite a while.

I'll add that I take back the git replay suggestion that I made above, for a number of reasons:

• the behavior when there are conflicts would be sub-optimal, as mentioned above
• it wouldn't support cherry-picking merge commits, which is an important feature (our normal cherry-pick doesn't support it either right now, but this should be fixed)

Which means that we are left with the original approach, which seems to be implemented by #3288.

Let me also add that I'm not a fan of this feature. It adds complexity to our code base that I find unnecessary; I find it easy enough to check out the destination branch manually and paste the commits there. Not a blocking objection if enough people find it useful, just wanted to mention it.

[RyanTalbot]

Hmm, I did miss #3288 somehow @stefanhaller. Looking to get more involved with the project so I'll keep looking around for other issues I can help with.