lkml.org 
[lkml]   [2014]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectHandling commit change logs (was: [PATCH v3 13/15] cpufreq: Add cpufreq driver for Tegra124)
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-08-20 22:21    [W:0.081 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site