[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl5-porters
Subject:    Re: [PATCH] backport of: fix setuid execution that was broken by
From:       Sam Vilain <sam () vilain ! net>
Date:       2009-08-31 21:31:50
Message-ID: 1251754310.11203.11.camel () maia ! lan
[Download RAW message or body]

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?

Sam

[prev in list] [next in list] [prev in thread] [next in thread]