<div dir="ltr">This comes up periodically, and we've had split opinions for a long time. I've been in the camp that likes merging, and finds it intuitive. But I'm open to trying cherry-picking since there is a lot of interest.<div><br></div><div>I must admit, I am always surprised when people describe merging forward as complicated. For me, it boils down to this:<div><br></div><div>- Features happen on master. No merging or cherry-picking required.</div><div>- Bug fixes happen on the last release branch. Merge your bugfix branch to master and the release branch. Simple.</div><div>- Hotfixes are a rare exception that require slightly more thought, but are still easy to reason about. If in doubt, "git merge-base [list all the places you want to merge your fix]" tells you where to branch from.</div><div><br></div><div>That's the extent of my thought process when merging forward. I am generally interested to know more about how this process causes friction.</div><div><br></div><div>But all of that said, I'm very happy to give cherry-picking a try. As Brian said, my main concern would just be tracking where a change has been applied. This is something I value a lot in the merge model.</div><div><br></div><div>If we do switch, I think we should first write down specifically what benefits we expect to get. That would help in two ways: 1) Make sure everyone is on the same page about what we expect to gain. I suspect there are differing assumptions across the group. 2) Enable us to evaluate afterward to what extent the change was successful.</div></div><div><br></div><div>Lastly, our current branching model was inspired by this classic approach:</div><div><br></div><div><a href="http://nvie.com/posts/a-successful-git-branching-model/">http://nvie.com/posts/a-successful-git-branching-model/</a><br></div><div><br></div><div>If you're not familiar, it's worth a read for perspective. Their "develop" branch is our "master". And obviously we don't do things in quite the same way, but the general principles are the same. </div><div><br></div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 2, 2017 at 3:34 PM, Brian Bouterse <span dir="ltr"><<a href="mailto:bbouters@redhat.com" target="_blank">bbouters@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The main concern for me is how to track the cherry picks in Redmine. Using the rebase and merge approach, or if Github had a dedicate cherry pick feature, we still need a way in Redmine to know if any given bugfix has been applied to older release streams, i.e. the current bugfix release stream.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 12:18 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="m_2115378570480106751m_-8007586272740299892gmail-ajy">> <img class="m_2115378570480106751m_-8007586272740299892gmail-ajz" id="m_2115378570480106751m_-8007586272740299892gmail-:t6" src="https://mail.google.com/mail/u/1/images/cleardot.gif" alt="">Thinking out loud, it would be nice if github would support a "cherry pick" PR<br><br></div><div class="m_2115378570480106751m_-8007586272740299892gmail-ajy">I think you can. The submitter just needs to open a PR against some branch other than master, and the merger needs to select the <a href="https://github.com/blog/2243-rebase-and-merge-pull-requests" target="_blank">rebase and merge</a> GUI option.<br></div></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>