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
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
