Apply patch from clipboard

[jesseduffield]

Is your feature request related to a problem? Please describe. We already have a couple ways of copying a patch to the clipboard:

• 'Copy patch to clipboard' option in custom patch options menu
• 'Diff of all files' / 'Diff of selected file' in files view 'Copy to clipboard' menu

But we don't have any keybindings for actually doing something with that patch once it's copied.

I had a use-case for this recently where I wanted to copy a patch from one repo to another (we were migrating to a monorepo). I had to apply the patch manually via pbpaste | git apply (works on mac).

Describe the solution you'd like I'm thinking this keybinding should live in the 'Patch options' menu, as an option labeled 'Apply patch from clipboard' (and 'Apply patch from clipboard in reverse'). Currently if custom patch mode is not active, we show an error rather than display the menu, so now we would instead just have that error appear as a disabled reason against each menu item that actually requires a custom patch.

To increase discoverability, we should add a tooltip to the file view's copy-diff-to-clipboard options mentioned above explaining how to go about applying the patch (i.e. press ctrl+p to bring up patch options menu and then select 'Apply patch from clipboard'). I also think we should add the file view's copy-diff-to-clipboard options to the patch options menu so that in order to satisfy the use case you only need to use one menu.

What do people think?

[stefanhaller]

A few thoughts:

• Where to put it: I wouldn't put it in the custom patch menu. The custom patch functionality is one of lazygit's most awesome features, but I have seen people have trouble wrapping their heads around how it works (or even just discovering it), and I'm worried that we make this even harder to understand by putting "unrelated" things into that menu. It's not unrelated in the sense that it has "something to do with patches", sure, but unrelated in the sense that it doesn't belong to the custom patch functionality. I'd just make it a separate command, I guess.
• apply vs. am: when moving commits from one repo to another it is often more useful to use git am than git apply, because it also takes over the commit message and author information from the original commit. I wonder how we let users chose between the two; showing a menu with the two options is the obvious solution, but we could also consider making the choice automatically for them based on what's in the clipboard (e.g. whether it starts with diff --git, in which case am won't work).
• -p: very often when moving patches between repos that don't have the same directory structure (e.g. from a submodule to a monorepo) I have to add either the -p option or the --directory= option (or both) to adjust the paths. For example, when making changes to gocui in the vendor directory, and then moving the change to the gocui repo, I have to apply the patch with -p5 over there. I'm unsure how we make these options available to users, but I feel without it the feature is not valuable enough.

[mark2185]

but I feel without it the feature is not valuable enough

I beg to differ, "not able to apply a patch" vs "can apply patch (either am or apply) in reverse if need be" is a pretty big step up.

I don't have a good idea about providing the configuration of -p or --directory, sadly, but I do think it shouldn't be a part of the custom patch menu.

[stefanhaller]

I thought about this more during my morning run, some more thoughts:

• I think it should go in the y menu. Right now the menu is called "Copy to clipboard", but we could rename it to "Clipboard operations" or something like that. This may be best for discoverability, because they probably created the patch from there in the first place.
• For the am vs. apply question, we could decide to always use apply in the files panel (menu entry: "Apply patch from clipboard"), and always use am in the commits panel (menu entry: "Create commit from patch in clipboard"). This would be nicely analogous to creating commits with shift-V.
• Before we start to use git am in lazygit we should first fix #1807. (It is relatively high up on my long list of things to work on after the release.)