On Thu, May 7, 2015 at 11:50 AM, Maxim Uvarov <[email protected]> wrote:
> Here I have patches from api-next needed to be merged to master: > > > https://git.linaro.org/people/maxim.uvarov/odp.git/shortlog/refs/heads/api-next > > There are 4 commits: > 5f9b8df example: classifier: remove odp_pmr_create_range() support > dab82ac validation: remove test case for odp_pmr_create_range() function > 3bd420c api: classification: remove odp_pmr_create_range() function > definition. > 088cea5 linux-generic: classification: remove odp_pmr_create_range() > function implementation. > The only thing wrong I see with this sequence is the removal of the API should be last, so reverse the order of patches 3 and 4. > > Which breaks git bisect. So I'm thinking what is better to do here merge > them to one commit or > leave as is. > > pros for not squash to 1 patch: > + logic split patches from api, validation and example easy for post merge > review. > > cons for not squash to 1 patch: > - not git bisect command friendly, but commits grouped and followed one by > one. > So that git bisect --skip can avoid this block; > > > pros to squash to 1 patch: > + git bisect friendly; > > cons to squash to 1 patch: > - one monster patch. > > For now I think it's better to not squash that commits to single commit. > Any ideas what is better to do in that case? > I think we should define somewhere that such separation for api patches & > tests are acceptable. > > Thanks, > Maxim. > > > > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
