On 02/12/16 13:46, Ryan Harkin wrote: > Hi Laszlo, > > Great writeup! I learned a few tips, for sure.
Thanks! > On 12 February 2016 at 01:09, Laszlo Ersek <[email protected]> wrote: >> (08) Standing in your edk2 clone, implement the following setting >> (requires customization): >> >> git config commit.template \ >> FULL_PATHNAME_OF_FILE_CREATED_IN_LAST_STEP >> > > Now, I wish I'd known about this before I went to the bother of > creating a prepare-commit-msg hook (attached for your amusement at the > wasted effort) > > The concept of using a hook might be more flexible in theory, but in > practice, a template is perfect for most people. I do have two hook scripts (post-checkout and post-merge) that update my tags file automatically. So hooks are indeed powerful. But the amount of comments in your hook script implies you had to think way too much for that Contributed-under tag! :) >> (23) Now we'll format the patches as email messages, and send them to >> the list. Standing in the root of your edk2 directory, run the >> following (note that the "-O" option needs customization: please >> update the pathname to the file created in step (10)): >> >> rm -f -- *.patch >> >> git format-patch \ >> --notes \ >> -O"/fully/qualified/path/to/edk2.diff.order" \ >> --cover-letter \ >> --numbered \ >> --subject-prefix="PATCH v1" \ >> --stat=1000 \ >> --stat-graph-width=20 \ >> master..implement_foo_for_bar_v1 >> >> This command will generate an email file for each one of your >> commits. The patch files will be numbered. The file numbered 0000 >> is a *cover letter*, which you should edit in-place: >> >> - in the "Subject:" line, summarize the goal of your series, >> >> - in the message body, describe the changes on a broad level, >> >> - *reference*, by complete URL, the "implement_foo_for_bar_v1" >> branch in your personal GitHub repo -- the one that you pushed in >> step (22), >> >> - finally, add *all* of the Cc: tags to the cover letter that you >> used across all of the patches. This will ensure that even if a >> maintainer is involved in reviewing one or two of your patches >> across the series, he or she will get a copy of your cover >> letter, which outlines the full feature or bugfix. >> >> (24) Time to mail-bomb the list! Do the following: >> >> git send-email \ >> --suppress-cc=author \ >> --suppress-cc=self \ >> --suppress-cc=cc \ >> --suppress-cc=sob \ >> [email protected] \ >> *.patch >> >> This command might ask you about sending the messages in response >> to another message (identified by Message-Id). Just press Enter >> without entering anything. >> >> You might want to run the command first with the --dry-run >> parameter prepended. >> >> The messages will be posted to the list only, and to the >> maintainers that you Cc'd explicitly in the commit messages. >> >> Once the messages are sent, you can remove the local patch files >> with: >> >> rm -f -- *.patch >> > > Is there an advantage to your workflow? > > I appreciate that there are many ways to do the same task, but I find > it more efficient to use "git send-email > master..implement_foo_for_bar_v1 [various options]" because it gives > me 1 step in 1 command rather than 2 steps in 3 commands. > > I can see that a v2 of a patch series would be easier if I stored the > 0000*.patch file rather than deleted it. For me, separating the formatting and mailing steps has a few advantages: - I get to look at the exact, formatted patch message. I like to verify how the diffstat looks, if the notes (from git-notes) are there, and so on. - As you say, I preserve the patch files. (In fact I have one big, concatenated mbox file per posting per series.) I don't just preserve the patch files / series file until the work gets merged -- I preserve my postings *forever*. Occasionally it allows me to grep for stuff I vaguely recall from my patches, very quickly and targeted-ly. - Reiterating the blurb in the v(n+1) cover letter is indeed one use case. - I have an additional, personal check that I like to do before posting v(n+1). I compare the mbox files (the concatenated series mboxes) between v(n) and v(n+1). This gives me a kind of "interdiff". I mainly use it to verify that I have listed *all* inter-version code changes in the per-patch git-notes sections. I like my git-notes to be complete; that's when they help the reviewer best. Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
