$ git format-patch <...>to create a set of patches, he wrote a new script which is invoked as
$ git patch-set <...>Each invocation creates a new patches/patches-<date>-<revlist> directory under a project's top-level directory and stores the set of patches there as one group. As a convenience, it also creates a <top>/patches/latest link to point to the location of the set of patches produced by the most recent git patch-set invocation.
Why would you ever need something like this? If you're working with a set of patches and some of them need to be re-worked, it can become confusing to remember which set of all the xxxx-your-change.patch files in your current directory need to be sent with git send-email. Using this tool helps keep each group of patches you generate separate from each other so when it comes time to send your patches upstream, you only need to run:
$ git send-email patches/latest/*patchI decided to give Peter's extension a try today and found it quite nice.
As I was exploring his git extensions I also stumbled upon git-extras which is quite nice too, and a little more polished.
While using Peter's git patch-set, it seems obvious to me that he uses a specific set of options to git format-patch which, I assume, are what he needs to use when submitting patches to the projects on which he works. Unfortunately I need to use a different set of options. So instead of hard-coding the set I want for my needs, I decided to fork his repository and update his git-patch-set script to be more generic. My changes assume the last argument in the git patch-set <...> command is the rev-list, but that all other options are to be passed to the internal call to git format-patch without assuming any defaults. So now I can use the following command to get my patches made the way I need:
$ git patch-set -M --subject-prefix="component][PATCH" \ --cover-letter master..mywork
I also added a Makefile in order to make it easier to install into one's system.
No comments:
Post a Comment