I’ve been working on the PUP for cherry-picking changes across our branches and I’ve opened a PR. Feedback would be much appreciated.
https://github.com/pulp/pups/pull/3 Also, I wanted to mention that it might be worth discussing how we can improve our merge forward process even if we don’t want to use cherry-picking instead. We’ve seen a couple accidental merges and I was wondering if there might be some way to prevent that? Two options I can think of. First maybe we could merge forward less often? I’m not sure how to time this. Secondly, perhaps we could use code reviews/PRs to confirm merges? Thanks. David On Tue, Mar 21, 2017 at 4:08 PM, Brian Bouterse <[email protected]> wrote: > I would really like to collaborate on this. First one to start it; let the > other know. > > On Tue, Mar 21, 2017 at 3:18 PM, David Davis <[email protected]> > wrote: > >> So I was planning on doing that actually. Although, if you have the spare >> cycles, go for it. >> >> >> David >> >> On Tue, Mar 21, 2017 at 2:49 PM, Brian Bouterse <[email protected]> >> wrote: >> >>> I plan to turn this thread into a formal RFC once that process has been >>> ratified. >>> >>> On Tue, Mar 21, 2017 at 11:13 AM, Sean Myers <[email protected]> >>> wrote: >>> >>>> On 02/06/2017 12:09 PM, Ina Panova wrote: >>>> > Seems like we are trying to choose/figure out what's more important - >>>> > linear commit history which is readable or confidence and ability to >>>> track >>>> > where exactly change had been applied? >>>> > >>>> > I agree with Mike and think that merging forward is so super simple, >>>> i must >>>> > admit i had issues to understand this strategy from the beginning but >>>> now i >>>> > could do that even with closed eyes. >>>> >>>> The problem, as has become very clear in the past few days, is that >>>> merging >>>> forward does not give us the confidence (or ability) to track where >>>> exactly >>>> a change has been applied. All it tells us is what commit hashes exist >>>> on a >>>> branch, which is not the same thing. You can record a commit hash as >>>> merged >>>> without bringing its changes forward, which is a necessary step in >>>> fixing >>>> merge-forward mistakes. The best way to see if a specific change exists >>>> on >>>> a given branch, whether we're cherry-picking or we're merging forward, >>>> as I >>>> understand it, is to use 'git cherry'. >>>> >>>> >>>> _______________________________________________ >>>> Pulp-dev mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>> >>>> >>> >>> _______________________________________________ >>> Pulp-dev mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/pulp-dev >>> >>> >> >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
