Add action to apply patchset to a target kernel tree and branch

[davidbtadokoro]

Description:

A core expected feature of patch-hub is to apply a patchset on top of a kernel tree and branch through the tool. This action encompasses some steps:

1. Resolve a kernel tree and branch as a base
2. Make sure that the working tree is clean (there isn't any rebasing, changes to commit, and the like)
   2a. (optional) If it is possible to save the dirty state (with stashing, for example), we should
3. Create a git branch on top of the resolved branch and checkout to it. The name pattern can be something like <base-branch>-<patchset-ID>-timestamp>. IMHO, the <patchset-ID> should be human-readable and easily relatable to the patchset
4. Resolve the applicable patchset file, which is guaranteed to be in the user fs (by default, at ~/.cache/patch-hub/patchsets/)
5. Try to apply the patchset with git am <applicable-patchset>.
6. If the patchset application succeeds or fails, notify the user about it. Ideally, we should store this information in a file (as we do with the reviewed_patchset.json) to keep track of these runs and be able to display them in different forms.
   6a. (optional) If the patchset application fails, use a generated .rej file and prompt the user if patch-hub can try to "force-applying" it (with wiggle, for example).
7. Do cleanups. At least checkout to the original branch the tree was in.

Steps marked with optional mean that, at least in the first version, we can simplify the feature and add these complexities later.

Motivation:

This feature is a must, not only because this is one of the reviewing workflows that patch-hub aims to cover but also because the action of issuing a kernel build has the patchset application as a pre-requisite.

[davidbtadokoro]

Hey @rodrigosiqueira, and sorry for bothering you. Could you check if the steps I described for applying a patchset make sense?

[OJarrisonn]

I've just started implementing some accessory stuff to implement this (config options, ui, etc)

[davidbtadokoro]

I've just started implementing some accessory stuff to implement this (config options, ui, etc)

Nice! In our offline conversation, I think I explained the same as described in this issue. I will mark you as an assignee just for tracking.

[OJarrisonn]

• add config options to git am, kernel trees and the current tree
• let the user change the branch before applying

[rodrigosiqueira]

Hi @davidbtadokoro , this sequence looks great!

Just try to define some defaults but also provide an option for the user to change them. For example, for the branch name, maybe let the user define something different as a prefix (e.g., PATCHES_REVIEW-..., PATCHES_FOR_VERSION_X_..., etc)

[OJarrisonn]

Nice hint, implemented

[davidbtadokoro]

Hi @davidbtadokoro , this sequence looks great!

Just try to define some defaults but also provide an option for the user to change them. For example, for the branch name, maybe let the user define something different as a prefix (e.g., PATCHES_REVIEW-..., PATCHES_FOR_VERSION_X_..., etc)

Thanks for reviewing the steps and for the idea! I totally agree with this approach and welcome more suggestions if you have 🙏