On Fri, Dec 11, 2009 at 05:39:11PM +0000, Przemysław Firszt wrote: > Dnia 2009-12-10, czw o godzinie 10:22 +1000, Peter Hutterer pisze: > > > From dcdce0a4fe304d8d94ec9d55d3097ae45dd622a3 Mon Sep 17 00:00:00 2001 > > > From: Przemo Firszt <[email protected]> > > > Date: Wed, 9 Dec 2009 20:26:04 +0000 > > > Subject: [PATCH 3/3] Fix comment describing where are used area check > > > functions. > > > > > > The comment was irrelevant after WcmPointInArea, WcmAreasOverlap and > > > AreaListOverlap have been moved to wcmCommon.c in > > > f19847502e8a0767693bc54597f779370cfba643 > > > > sha's can't be used in patches that you send via email. The sha is generated > > when you commit, so once I apply the patch locally it has a different sha > > than on your machine. > It wasn't clear for me - thank for the explanation. > > > For patches like this it's better to either use the first line of the commit > > message (This comment is irrelevant since the patch "Move > > xf86WcmPointInArea, xf86WcmAreasOverlap & xf86WcmAreaListOverlap") or send a > > pull request for the patches in one go - pulling preserves the shas. > > > > for this patch, I just squashed it in with the first one, it's easier. > > (have a look at git rebase -i if you haven't yet, it's very useful) > OK, I'll do it that way next time. > > > Last thing before pushing - can I have your signed-off-by for these patches > > please? just in a reply to this email is enough. > You mean this: > Signed-off-by: Przemo Firszt <[email protected]> > > I hope it's OK...but I'm a git greenhorn
yes, thanks. the signed-off is simply your certificate of origin http://git.kernel.org/?p=linux/kernel/git/aegl/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=72651f788f4e3536149ef5e7ddfbed96a8f14d2f;hb=HEAD see Section 12) in that page, it essentially means that you're guaranteeing the patch is allowed in the project. git commit -s adds the signed-off-by tag automatically, you don't need to add it by hand. on that note, once you're starting to use git rebase, s-o-b becomes useful as a marker for finished patches. e.g. I develop a set of patches, then rearrange and squash them as needed and add my s-o-b to those I consider done. This way you can do a simple log and see immediatly which patches are ready for sending to the list and which ones need more work. just one possible workflow, it helps me and it might help you too. Cheers, Peter ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
