Hi, The names remotes are given are completely arbitrary. It s normal to have one called origin, and the rest something else, but it is not mandatory to have that.
It is true the instructions below in places assume you will call your fork origin and the main MP one something else, and I tend to recommend the opposite. But, as long as you know what *you* called your remotes its easy to adapt any instructions to your situation. If you have not called the main MP repo origin, then you can still sync with it. > git pull —rebase —autostash <XYZ> master > sudo portindex replace <XYZ> with whatever you have called the remote in your checkout for the main MP repo. The above is in effect what 'sudo port sync’ does, if you have set things up such that port uses your checkout as its main source. However, it is not mandatory to use port sync, the above has the same result. Chris > On 24 Aug 2019, at 4:06 pm, Gerben Wierda <[email protected]> wrote: > > Yes, those were among the instructions I followed. But that gets me the > situation of which now is said doesn’t fit with port sync. e.g. those > instructions means my own fork is called origin and the macports fork is > called upstream. But port sync assumes differently (if I understand it > correctly) > > As I understand it, I need my own fork gctwnl/macports-ports because I am not > allowed to push to macports/macports-ports and I need to work with branches > inside my own fork. But how that whole landscape (a) keeps synchronised and > (b) works with the port command is unclear, also after reading that info. > > Gerben Wierda > Chess and the Art of Enterprise Architecture <http://enterprisechess.com/> > Mastering ArchiMate <http://masteringarchimate.com/> > Architecture for Real Enterprises > <https://www.infoworld.com/blog/architecture-for-real-enterprises/> at > InfoWorld > On Slippery Ice <https://eapj.org/on-slippery-ice/> at EAPJ > >> On 24 Aug 2019, at 16:47, Ryan Schmidt <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Aug 24, 2019, at 07:55, Gerben Wierda wrote: >> >>> I have been trying to follow instructions but I am trying to prevent to >>> have to become a git expert (there is insufficient time for that available, >>> such as studying a whole git book). Just knowing some basic recipes for >>> actions/steps lets me concentrate on the actual stuff I want to do that is >>> potentially contributing to ports. >>> >> >> We have some help available here: >> >> https://trac.macports.org/wiki/WorkingWithGit >> <https://trac.macports.org/wiki/WorkingWithGit> >> >> We needed a cheat sheet for people like you and me who don't have time to >> learn git, and other developers more familiar with git thankfully pitched in >> to write that. If it's missing anything you'd find helpful, please add it or >> suggest what should be added. >> >
smime.p7s
Description: S/MIME cryptographic signature
