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.

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.

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.

Else, you could also have a look at "git rerere" ( https://git-scm.com/blog/2010/03/08/rerere.html or https://git-scm.com/docs/git-rerere ). 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.

Also, squashing commits sometimes helps to reduce the repetitive rebase work. But you loose history.

Hope it can help... And still looking for 'the way'!

Joel

On Thu, Sep 29, 2016 at 3:04 AM, mike thompson <mithomps@redhat.com> wrote:

Hey Hawkular Folk,

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.
I have asked around, and no one is confident in “the way”.

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.

— Mike

_______________________________________________
hawkular-dev mailing list
hawkular-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev