[Maverick][GIT PULL] replacement of hacks with Yama

[Leann Ogasawara]

On Thu, 2010-07-01 at 09:01 -0400, Chase Douglas wrote:
> On Thu, 2010-07-01 at 06:51 -0600, Tim Gardner wrote:
> > On 06/30/2010 03:30 PM, Leann Ogasawara wrote:
> > > On Wed, 2010-06-30 at 13:45 -0700, Kees Cook wrote:
> > >> Hi Tim,
> > >>
> > >> On Wed, Jun 30, 2010 at 08:12:24AM -0600, Tim Gardner wrote:
> > >>> These commits all have '(cherry picked from commit *)' comments in
> > >>> the commit log, but as the objects are not from Linus' tree, they
> > >>> are not relevant. Can you amend these commit log messages?
> > >>
> > >> Ah, sorry, they're from security-testing-2.6#next:
> > >> http://git.kernel.org/?p=linux/kernel/git/jmorris/security-testing-2.6.git;a=shortlog;h=refs/heads/next
> > >>
> > >> What is the best way to reference these kinds of cherry picks?
> > >
> > > I don't think we've standardized on a syntax but something like the
> > > following would be fine with me:
> > >
> > > (cherry picked from commit<insert sha1>
> > > from git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git next)
> > >
> > 
> > This is a bit of a nit, but even that syntax is superfluous because 
> > James Morris tree is not immutable. Like all of the 1st and subsequent 
> > level maintainers he must occasionally rebase his tree which renders all 
> > SHA1 references to his tree invalid.
> > 
> > The only trees that are never rebased are Linus' and the post release 
> > Ubuntu repos.
> 
> I think it's useful just as we submit patches. If a patch comes from
> someone we don't know already, we can double check it before we apply it
> to our tree.
> 
> However, I don't see the usefulness once it has been applied to our tree
> because upstream may rebase. Maybe we should strip them before we apply?

I can see dropping mention of the sha1 because as Tim mentioned, a
rebase will render it invalid.  However, I do like having some sort of
paper trail in the commit to track the patch's upstream progress/status.
I found this sort of information useful when reviewing our Ubuntu delta
at the beginning of the cycle.

Thanks,
Leann