Handling commit change logs (was: [PATCH v3 13/15] cpufreq: Add cpufreq driver for Tegra124)
From: Andreas Färber <afaerber@suse.de>
Date: 2014-08-20 20:02:36
Also in:
linux-arm-kernel, linux-pm, linux-tegra, lkml
Hi Javier, Am 20.08.2014 17:39, schrieb Javier Martinez Canillas:
As you already know when you apply a patch with git am, everything that is between a line with 3 dashes line (---) and the actual diff is omitted since that is where the generated diffstat is placed by git format-patch. We usually rely on that behavior to put there the history of a patch or any information that we think that is useful for reviewers but is not suitable to end in the commit message. Now that means that you have to generate the patch and then manually edit it to add the history there. But since git am omits any text between the first "---" and the diff, it means that you can add a "---" on your actual commit message and anything that follows will be discarded by git am, that way you can maintain your history on your commit message which is way less tedious than manually editing patches. So the second "---" from Tuomas patch is actually the one generated by git format-patch but that gets discarded by git am just like any other text so it causes no harm when other apply the patches. If this not the correct workflow and you have a better way to manage this, I would love to know about it.
One drawback of having --- in the commit message is that you can't cherry-pick but really need to use git-am for it to be stripped. I resorted to a scripted way of handling change logs: Per patch series I maintain a shell script that after git-format-patch essentially runs sed -i "/---/ r /dev/stdin" $OUTDIR/0001-*.patch <<EOCL ... EOCL to insert my text after ---. (sed syntax is not POSIX-compliant FWIW.) Similarly I fill in the blurbs for the cover letter. Another way I've heard of is git-notes, which lets you associate text with a given commit id. But in my tests that data did not survive a git-rebase -i, it stayed attached to the original commit when editing the commit message or fixing up a patch. It could still be accessed through the list of git-notes but not be comfortably extracted from the updated branch via git-rev-list or the likes. Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg