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? SamThread Previous | Thread Next