[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikjQuwvD4A0do0RAYheDKFeeXndjtDQvQC2WXEw@mail.gmail.com>
Date: Fri, 3 Dec 2010 09:33:17 -0500
From: Eric Paris <eparis@...isplace.org>
To: ext-jarkko.2.sakkinen@...ia.com
Cc: jmorris@...ei.org, casey@...aufler-ca.com,
linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: VS: [PATCH] Smack: label for task objects (retry 2)
On Fri, Dec 3, 2010 at 1:27 AM, <ext-jarkko.2.sakkinen@...ia.com> wrote:
> Hi
>
> I don't like to whine about unnecessary things but it would really nice to get into the author field :) The patch that I sent to list did have merge issues. I don't know what messed it.
>
> Casey, I propose we take some steps back and fix the workflow so next time things will go smoother. I propose that I create my own tree from your tree and put patch there and you can then cherry pick or merge my patch to his tree. Then James can pick the patch from your tree.
>
> BR, Jarkko
You can't apply Sign-off's on a git-pull/git-merge. I'm not sure if
James cares that he didn't sign the patch off either. That doesn't
mean one can't do it, it just means it isn't an easy workflow.
If git tree owners use git am to apply mboxes (rather than patch + git
commit) the author/time/date type stuff will be correct. The fact
that the original author forgot the signed-off is a problem unrelated
to git usage.
Now how could security set up git trees? That is the question.
1) 'child' trees (I see child tree as the SELinux or SMACK tree)
should NEVER be based on something newer than security-testing.
Personally I don't think security-testing should merge Linus' except
maybe 2 times per upstream kernel cycle. At release and then about
-rc4 or 5. If we are doing things right security-testing shouldn't
need to merge ever, but I digress. Linus would MUCH rather deal with
conflicts himself than have development trees merge his work quickly
or regularly. That's a problem for James to deal with I guess. We as
child tree owners need to just base off of James.
2) If #1 is true and you want to get Sign-off's in your parent tree
you can set up the child trees as a remote. Then you can use:
git format-patch -k --stdout HEAD..remotes/[child]/[branch] | git am
-3 -k --whitespace=fix -s
Where you obviously set child/branch appropriately. This will apply
the patches found in the child tree but not in the parent tree (which
is the reason the child must be behind) one at a time and will add
your Signed-off.
The problem with this method is that it makes it harder to check if
the pull request was done properly. A merge gives a unified diff that
can be compared to a properly formated (git request-pull) pull request
to make it easy for the puller to verify he pulled what he was ask to
pull. So the parent tree has to do that unified diff themselves and
double check.
Our tree is so simple I don't really understand why we need all this,
but if we need it, lets figure out what works best for everyone!
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists