Thread (32 messages) 32 messages, 8 authors, 2014-08-21

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help