I''m probably going to help backport some code from master onto 3.2, and the suggested process in the Contributing guide doesn''t actually look like the best approach to me. Wouldn''t it make more sense to just check out the branch you want to patch, cherry-pick the change(s) from master, make any additional commits necessary to get it working? Not only is that simpler than what is suggested, it easily handles changes that were committed to master long ago and/or are spread across multiple non-consecutive commits. Assuming that sounds right, shall we update the guide? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/eQBnC0vZQHIJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Rafael Mendonça França
2012-Aug-13 17:27 UTC
Re: Backporting instructions in Contributing guide
On Mon, Aug 13, 2012 at 2:20 PM, Steve Jorgensen <stevej@stevej.name> wrote:> I''m probably going to help backport some code from master onto 3.2, and > the suggested process in the Contributing guide doesn''t actually look like > the best approach to me. Wouldn''t it make more sense to just check out the > branch you want to patch, cherry-pick the change(s) from master, make any > additional commits necessary to get it working? >Yes. This is exactly what I do. But, you should not add more commits. Just cherry-pick and amend the commits. This will make easier to track backports. Also, I usually cherry-pick the merge commit when it exists so it will point to the pull request too. I don''t know if the others Rails committers agree but this is my workflow to backports.> > Not only is that simpler than what is suggested, it easily handles changes > that were committed to master long ago and/or are spread across multiple > non-consecutive commits. > > Assuming that sounds right, shall we update the guide?Yes, please.> > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/eQBnC0vZQHIJ. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
+1 I think I wrote the original guide on back porting and this definitely sounds like a better approach. Godfrey Sent from my phone On 2012-08-13, at 10:27 AM, Rafael Mendonça França <rafaelmfranca@gmail.com> wrote:> On Mon, Aug 13, 2012 at 2:20 PM, Steve Jorgensen <stevej@stevej.name> wrote: >> I''m probably going to help backport some code from master onto 3.2, and the suggested process in the Contributing guide doesn''t actually look like the best approach to me. Wouldn''t it make more sense to just check out the branch you want to patch, cherry-pick the change(s) from master, make any additional commits necessary to get it working? > > Yes. This is exactly what I do. But, you should not add more commits. Just cherry-pick and amend the commits. This will make easier to track backports. Also, I usually cherry-pick the merge commit when it exists so it will point to the pull request too. > > I don''t know if the others Rails committers agree but this is my workflow to backports. > >> >> Not only is that simpler than what is suggested, it easily handles changes that were committed to master long ago and/or are spread across multiple non-consecutive commits. >> >> Assuming that sounds right, shall we update the guide? > > Yes, please. > >> >> -- >> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. >> To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/eQBnC0vZQHIJ. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Mon, Aug 13, 2012 at 10:50 PM, Godfrey Chan <godfreykfc@gmail.com> wrote: +1> > I think I wrote the original guide on back porting and this definitely > sounds like a better approach. >Sounds good. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.