Basic `git am` support

[OJarrisonn]

This is still a draft for this feature. The purpose of this is to implement just the backbone for the patch apply feature for patch-hub

What Is This?

This PR introduces an apply feature for patch-hub that let's kernel developers select a given patchset and apply it on a given kernel tree.

How it Works?

Currently open the details of a patchset and then press a. This will run git am in the background and try to apply the selected patchset to the selected kernel tree.

At the moment, you need to manually set some configurations in the config.json file in order to use this feature. The configs are:

• git_am_options: a string with options to be passed to git am command (similar to git_send_email_options)
• kernel_trees: an object to indicate which kernel trees you're working on. The key specifies the name of the kernel tree (any name you want) the value is the path to the kernel tree
• current_tree: a string that specifies which of the above declared kernel trees are you working on, this is used when applying the patchset so patch-hub automatically cds into the right directory
• git_am_branch_prefix: for higienic reasons this feature creates a new branch when applying the patch, this option let's you configure a prefix for this branch's name

Applying a patchset is done in a couple of steps:

• cd into the tree: use the current_tree option and kernel_trees to find out where patch-hub is suposed to find the kernel tree where to apply the selected patchset
• Create a branch: once in the kernel tree directory, create a new branch use the specified prefix and the current timestamp (YYYY-mm-dd-HH-MM-SS)
• Apply the patchset: when opening a patchset to show the details, we store the patch to the .mbx file in a field called path in the PatchsetDetailsAndActionsState struct. When then use Command to run git am with the given git_am_options to try to apply the patchset in the newly created branch
• Did it succeed?: check if the apply worked. If not we call git am --abort to clean the state of the tree and log any useful information
• Clean it up: once we applied (or not) the patchset we git checkout - and cd back to the directory we where when we started the apply. Also if git am failed we delete the branch

What's next

• Let the user define kernel trees in-app
• Let the user select a tree
• Let the user checkout a branch before applying
• Let the user decide how to handle errors (abort, manually, automatically(?))
• Provide an app screen with all the above
• Write tests

@davidbtadokoro this PR works but there is no intuitive UI/UX for it so needs more polishing before being merged

@rodrigosiqueira any more hints about what a kernel developer might want when applying a patchset is welcome

[OJarrisonn]

All comments resolved

[davidbtadokoro]

Hey @OJarrisonn , I was thinking about revisiting the old implementation of patch-hub in Bash to see how I handled the setup of the repo before applying (checkout to the branch, guaranteed that the working directory is clean, etc.). If there is something we can leverage, I will bring it for us to merge this more robustly.

Of course, as we talked in the past days, the full notification about success and what else will become viable once we implement the pop-up system, but this sanitizing setup and teardown are worth for this PR.

In any case, be right back 🤝

[OJarrisonn]

I think it might be worthy to add a step to stash any changes just after cding into the tree and unstashing before cding back