On 2015-05-07 16:26, Bill Fischofer wrote: > 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.
That wont work, because the patches don't do what it stats its doing in the commit log... For instance: api: classification: remove odp_pmr_create_range() function definition Don't lie there, however, it does a lot more e.g., remove odp_pmr_create_match() and add odp_pmr_create() function What we should have done would be to add a first api patch that adds the new api + implementation for that and then build the 4 patches on that. For this specific case we can either look the other way and hope we will never need to do git bisect below this point, squash the patchset or revert it and redo the patchset. Cheers, Anders > > > > > > 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 -- Anders Roxell [email protected] M: +46 709 71 42 85 | IRC: roxell _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
