On 3 June 2015 at 19:39, Laszlo Ersek <ler...@redhat.com> wrote: > On 06/03/15 19:08, Ard Biesheuvel wrote: >> On 3 June 2015 at 19:03, Laszlo Ersek <ler...@redhat.com> wrote: >>> On 06/03/15 18:14, Ard Biesheuvel wrote: >>> >>>> Thanks, pushed as r17554 >>> >>> Congrats to your first (am I right?) SVN commit! >>> >> >> Indeed! >> >>> A small tip (feel free to ignore it): since for edk2 patches, the >>> tianocore contribution agreement is needed, it's useful to set up a >>> commit message template. Something like: >>> >>> [commit] >>> template = /home/ardb/misc/tianocore.template >>> >>> where the referenced file would say: >>> >>> -------------- >>> >>> >>> Contributed-under: TianoCore Contribution Agreement 1.0 >>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> >>> ----------------- >>> >> >> Yes, I am using that already >> >>> The "trick" I'm proposing here is that you include your S-o-b with the >>> template as well, since you "should" have a template anyway. (Or else, >>> pass --signoff to "git-commit".) >>> >> >> On other projects, I am used to doing 'git commit -s' to add the >> signoff. I never rely on git-format-patch to do that. >> >>> Additionally, ask git-format-patch not to generate your S-o-b's on the fly: >>> >>> [format] >>> signoff = false >>> >>> Your posted patches will look the same, but the difference will be that >>> your commit messages themselves will include your signoffs; the S-o-b >>> tags won't be generated *only* when formatting the patches. >>> >>> Why is this good? Because the resultant signoffs-in-commits will be >>> consistent with patches that you apply from others (with git-am), and >>> because this way you can add my R-b tag *after* your S-o-b, via rebasing. >>> >> >> I added it before deliberately, since the signoff that comes after it >> then signifies that *I* was the one that added the R-b, not someone >> that handled and signed off on the patch after me. >> >> For instance, in kernel commits, you may see something like: >> >> """ >> Signed-off-by: Javier Martinez Canillas <javier.marti...@collabora.co.uk> >> Reviewed-by: Doug Anderson <diand...@chromium.org> >> Signed-off-by: Kukjin Kim <kg...@kernel.org> >> """ >> >> (https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/commit/8cf5e6dc8dd55d0f1ad46ab4046c3a8a51d2136d) >> >> where it is clearly the maintainer that picked up the R-b from the >> list, and not the author that added it. >> >>> Just my two cents (in a wall of text, sorry), feel free to ignore. >>> >> >> No, let's discuss ... :-) >> > > Haha, okay :) > > Since in this case you are both original author and maintainer, I think > you should add your Signed-off-by both before and after my Reviewed-by, > in essence taking both Javier's and Kukjin's roles. /deadpan > > In earnest tho, using your earlier (pre-maintainership) patches as an > example, let's say you posted a patch (first S-o-b), Olivier reviewed it > (R-b after first S-o-b), and (assume) I would apply it (second S-o-b, > presumably). In this case however I would simply not add my S-o-b, > because I had absolutely no input into it.
In the kernel, you *must* add your S-o-b if you are on the patch delivery path (unless the patch gets merged from a pull request) > Unless I forwarded that patch > (via formatting and posting it) or expected someone to pull my tree, > there would be no reason to add my S-o-b just for committing. > > Anyway, I shan't obsess about this again ;) > Good. ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
