<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">If you have not called the main MP repo origin, then you can still sync with it.</div><div class=""><br class=""></div><div class="">> git pull —rebase —autostash <XYZ> master</div><div class="">> sudo portindex</div><div class=""><br class=""></div><div class="">replace <XYZ> with whatever you have called the remote in your checkout for the main MP repo.</div><div class=""><br class=""></div><div class="">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.<br class=""><div><br class=""></div><div>Chris</div><div><br class=""><blockquote type="cite" class=""><div class="">On 24 Aug 2019, at 4:06 pm, Gerben Wierda <<a href="mailto:gerben.wierda@rna.nl" class="">gerben.wierda@rna.nl</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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)<div class=""><br class=""></div><div class="">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.<br class=""><div class=""><div class=""><div class=""><br class=""><div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Gerben Wierda</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://enterprisechess.com/" class="">Chess and the Art of Enterprise Architecture</a></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://masteringarchimate.com/" class="">Mastering ArchiMate</a></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://www.infoworld.com/blog/architecture-for-real-enterprises/" class="">Architecture for Real Enterprises</a> at InfoWorld</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://eapj.org/on-slippery-ice/" class="">On Slippery Ice</a> at EAPJ</div></div>
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On 24 Aug 2019, at 16:47, Ryan Schmidt <<a href="mailto:ryandesign@macports.org" class="">ryandesign@macports.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class="">On Aug 24, 2019, at 07:55, Gerben Wierda wrote:<br class=""><br class=""><blockquote type="cite" class="">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.<br class=""><br class=""></blockquote><br class="">We have some help available here:<br class=""><br class=""><a href="https://trac.macports.org/wiki/WorkingWithGit" class="">https://trac.macports.org/wiki/WorkingWithGit</a><br class=""><br class="">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.<br class=""><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></div></div></blockquote></div><br class=""></div></body></html>