develooper Front page | perl.perl5.porters | Postings from August 2009

Re: [PATCH] backport of: fix setuid execution that was broken by f20b29985d

Thread Previous | Thread Next
August 26, 2009 16:42
Re: [PATCH] backport of: fix setuid execution that was broken by f20b29985d
Message ID:
2009/8/26 Nicholas Clark <>:
> On Wed, Aug 26, 2009 at 08:55:44PM +0200, demerphq wrote:
>> 2009/8/26 Nicholas Clark <>:
>> > On Wed, Aug 26, 2009 at 03:29:58PM +0200, Rainer Tammer wrote:
>> >> Hello,
>> >> please could someone with commit right apply the attached patch to
>> >> maint-5.8 ?
>> >> If there will ever be a 5.8.10 then the suidperl problem would be fixed...
>> >
>> > Whilst agreeing with the intent, I disagree with the mechanism.
>> >
>> > Someone should cherrypick the correct patch from maint-5.10.
>> > They shouldn't cold apply patches to a branch, as git then fails to track
>> > what is not yet merged.
>> Er, I dont get it. Cherry picking /is/ applying patches. If the exact
>> same patch is applied by hand to two branches git will not know
>> whether it has been done by rebasing, cherry-picking or by hand. It is
>> all the same to git (message details aside, which git does not look
>> at.)
> We can't guarantee that it is the same patch, if it's sent via a mailing
> list and applied. (Hateful whitespace). Whereas "please cherry pick ${hash}"
> is reliable in the face of format F-word.

Aha. :-) Good point.

However the point remains. The actual process by which an identical
patch is applied to two branches matters not at all to git.

>> Also, IMO, and I say this only because 5.10.1 is out now, I think
>> patches for 5.8 should go to 5.8 first and THEN be applied to blead if
>> necessary. In fact, its arguable we should just start collecting topic
> This is a patch already in the maint-5.10 branch

I was speaking generally.

>> branches. And then rebase them into the other branches as needed. Then
>> there is no need for the "which patches have been back ported, etc"
>> type tracking. Either the topic branch has been merged/rebased into
>> the branch, or it has not.
> We substitute it with manually tracking "which branches have been merged"?

This is a considerably easier task than "what patches have been
cherry-picked,and or munged to be applied to a different branch" as
the task essentially involves checking that a particular commit
/message/ is in the branch. It ignores the code involved, and is
relatively easy to manage as a process. I dont know if you have worked
with topic branches. If not then I suggest you play with it a bit. It
makes life MUCH easier.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About