Community mailing list archives
Re: github practices for PRby
Camptocamp SA, Yannick Vaucher - Camptocamp
In this case I think you can only create your 2 PRs and see which one is accepted first to rebase the second one.
I would advise to separate completelly both PR and say it is required to merge `my_module` first (anyway tests will fail in this case as dependancy won't exists).
This doesn't seams to be possible in git.
In launchpad you could stack MP for `my_module_extended` on MP for `my_module`
I create 2 PR.
So I have to fix or port both modules from 7.0 to 8.0.
Here is the conext I can think of:I have module `my_module_exended` to port which depends on module `my_module`
And don't forget to add a little comment saying which one depends on which one.
Another use case would be to create 2 separates fixes that will conflict because they touch same code.
On Wed, Sep 10, 2014 at 10:44 AM, Lorenzo Battistini <firstname.lastname@example.org> wrote:
On 09/10/2014 10:01 AM, David Beal wrote: > Hi community, > > Git is really powerful but simple things are sometimes difficult. > > How to do a PR based on other PR to restrict files changed display to > only one PR. I'm not sure to understand the use case, but if you want to improve an existing PR, you can fork the feature branch involved in the PR and propose the changes there. See the recent events on https://github.com/OCA/hr/pull/17 As I wanted to help Sandy with that job, I forked his branch and made the first PR at https://github.com/savoirfairelinux/hr/pull/1 Regards -- Lorenzo Battistini Tel (CH): +41 91 210 23 40 Tel (IT): +39 011 198 25481 http://www.agilebg.com https://github.com/eLBati
Business Solutions Software Developer
PSE A, CH-1015 Lausanne
Phone: +41 21 619 10 30
Office: +41 21 619 10 10