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 <bbout...@redhat.com> 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 <sean.my...@redhat.com> > 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 >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev