<div dir="ltr"><div class="gmail_extra">I haven't found "the way" either, and the solution, if there's one, is probably tightly related to the kind of changes that are made.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Maybe something that can help is in the work organization (if it's not too late for you?): trying to separate on one side all the refactoring of the existing that could be merged seamlessly without impacting existing functionalities; and on the other side, all the functional stuff, feature changes and additions.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you're able to do that then merging the refactoring part in master would help a lot: as it doesn't change the existing, it should be easier to make the merge accepted by others; and it's the part that is the most likely to generate rebase or merge conflicts, the other part shouldn't generate much conflicts if it's all about new stuff.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Else, you could also have a look at "git rerere" ( <a href="https://git-scm.com/blog/2010/03/08/rerere.html">https://git-scm.com/blog/2010/03/08/rerere.html</a> or <a href="https://git-scm.com/docs/git-rerere">https://git-scm.com/docs/git-rerere</a> ). I used that some years ago in such situation, it allows git to "remember" conflict resolution to avoid you having to resolve again and again the same conflicts on long lived branches. However it has its downsides, it can be error prone because sometimes the resolution you did the first time doesn't apply as well some times later.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, squashing commits sometimes helps to reduce the repetitive rebase work. But you loose history.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Hope it can help... And still looking for 'the way'!</div><div class="gmail_extra">Joel</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 29, 2016 at 3:04 AM, mike thompson <span dir="ltr"><<a href="mailto:mithomps@redhat.com" target="_blank">mithomps@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Hawkular Folk,<br>
<br>
So I just wanted to know what is the ‘the way’ to incorporate branches or PRs that one’s branch is dependent on? Since merging into MiQ master takes so long, what is our strategy around dependent merges? We are unfortunately in the realm of long lived branches now. Much more rebasing and conflicts given the extended timeframes for merging.<br>
I have asked around, and no one is confident in “the way”.<br>
<br>
I have a couple methods in mind but not sure what the best practices are…. Please speak up if one works for you and we can adopt it.<br>
<br>
<br>
— Mike<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
</blockquote></div><br></div></div>