On 5 May 2015 at 11:27, Maxim Uvarov <[email protected]> wrote:
> On 05/05/2015 14:20, Savolainen, Petri (Nokia - FI/Espoo) wrote: > >> >> *From:*ext Maxim Uvarov [mailto:[email protected]] >> *Sent:* Monday, May 04, 2015 8:20 PM >> *To:* Savolainen, Petri (Nokia - FI/Espoo) >> *Cc:* [email protected] >> *Subject:* Re: Reverts in the repo ... >> >> On 4 May 2015 at 13:40, Savolainen, Petri (Nokia - FI/Espoo) < >> [email protected] <mailto:[email protected]>> wrote: >> >> >> >> > -----Original Message----- >> > From: ext Maxim Uvarov [mailto:[email protected] <mailto: >> [email protected]>] >> > Sent: Thursday, April 30, 2015 4:24 PM >> > To: Savolainen, Petri (Nokia - FI/Espoo) >> > Cc: [email protected] <mailto:[email protected]> >> > Subject: Re: Reverts in the repo ... >> > >> > On 04/30/2015 14:24, Savolainen, Petri (Nokia - FI/Espoo) wrote: >> > > .. are not user friendly. >> > > >> > > 1) git pull (in master) >> > > 2) git checkout api-next >> > > 3) git pull >> > > >> > > Results conflict in packet_io.h: >> > > >> > > <<<<<<< HEAD >> > > * @note dev name loop is specially pktio reserved name for device >> used >> > for >> > > * testing. Usually it's loop back interface. >> > > ======= >> > > * @note The device name "loop" is a reserved name for a loopback >> > device used >> > > * for testing purposes. >> > >>>>>>>> 0162f9e00e2b55a45aa391be512672a06ac03c30 >> > > >> > > .. and now *every* user need to fix this. This is an easy fix, but >> that >> > may not be always the case. >> > No, it's because you have that local change. Others will not see this. >> >> The same lines (of two versions of Bill's v1 and v2 commits) conflict >> also on branches that do not modify packet_io.h at all. I think that >> everyone that have pulled api-next after the v1 but before the v2 see the >> issue (when pulling now the v2). >> >> >> -Petri >> >> Petri, you should not use git pull for api-next. It's development branch >> and it supposed that you do something like that: >> >> git fetch >> >> git rebase -i FETCH_HEAD >> >> Maxim. >> >> Master and api-next should have the same work flow - either reverts are >> acceptable on both branches or on neither. >> >> In general, history rewriting should be avoided on public branches. Just >> fix mistakes with new patches/commits on top. Actual rewriting should be >> needed very rarely - e.g. to undo accidental addition of garbage >> (files/data that was never meant to be in version control). >> >> -Petri >> >> We have to define that or redefine. Before I had information that > api-next is development branch which can include raw patches with missing > sign offs. That patches can be updated to include sign-offs or new version > of patches. Agreed, we should have written down before, but I think now that we used if for one release we know what is working and can amend things. I still believe api-next needs to become a repo maintained by a driving force behind the api change. > > > Maxim. > > > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > -- Mike Holmes Technical Manager - Linaro Networking Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
