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

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

Thread Previous | Thread Next
Sam Vilain
August 31, 2009 14:32
Re: [PATCH] backport of: fix setuid execution that was broken byf20b29985d
Message ID:
On Wed, 2009-08-26 at 20:03 +0100, Nicholas Clark wrote:
> > 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.

The same problem (that is, patch IDs are different) will apply if you
had to manually merge the patch, or if the patch was merged with fuzz.
If you are concerned, note the commit ID that you are cherry picking and
the information will be there for future maintainers..

> > 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"?

Currently the back-porting pattern is more like "which changes on blead
have been merged?"  But to be honest I'm not sure how you keep track of
which patches were skipped because they should not be merged.  Is that
why there is a requirement for only one back-porting maintainer?


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