On 21 August 2016 at 22:47, Fred Wright wrote: > On Sat, 20 Aug 2016, Brandon Allbery wrote: >> On Sat, Aug 20, 2016 at 11:44 PM, Ian Wadham wrote: >> >> > Fork the repo?? >> >> github expects you to do this, yes. I don't actually recommend it because >> keeping up to date with the original repo's a PITA (and *not* automated in >> any way. https://help.github.com/articles/syncing-a-fork/ is annoyingly > > Umm, the whole merging aspect is something you need to do regardless of > whether you're pulling from "origin" or "upstream", so this isn't a good > argument against using a fork. It gets more complicated with multiple > branches, but again the merging part is the same whether you're using a > fork or not, and the only difference is whether you also need to push the > merged branches to the fork. > > Meanwhile, the whole pull request mechanism is designed around the forked > repo model, so anyone without direct commit access should be strongly > encouraged to use a fork. And even for someone *with* direct commit > access, a fork provides a backed-up sandbox for changes that aren't ready > for the main repo (even in a branch). > > There's a slight difference in whether you need to specify "upstream" in > the "fetch" or "pull" (since you don't normally want to make "upstream" > the default remote), but that's pretty minor.
I agree. Sure, updating your fork is not automated in any way, but not forking the repository doesn't make it any easier to deal with updates. You may do the following: - fork the original repository - git clone https://github.com/your-username/macports-ports.git - cd macports-ports - git remote add mp https://github.com/macports/macports-ports.git and then whenever you want to change something you do - git fetch --all - git pull mp master [- git push origin master (or whatever you call your own fork)] You only have to do that last step when you have something worth uploading, but the updates will go there automatically. Even if your fork is not kept up to date, the changes you made in one particular branch can still be fetched by interested users. (It actually doesn't matter if you clone from macports first and then add your own fork with "git remote add myowncopy https://github.com/your-username/macports-ports.git";. It's just a matter of which one will be called "origin" by default. You can rename it later anyway.) When submitting pull request one can create a new branch, make a pull request, then delete that branch (or delete the fork for that matter). >> manual). You lose the ability to maintain your clone with github's web >> interface, but that's not much of a loss really. (Or you can do their thing >> in reverse: clone the repo, add github as an additional upstream, create a >> new empty repo (not a fork) via their web interface, push to github >> periodically as a backup.) Sure, but you end up with exactly the situation described above. In what way is creating an empty repository easier than forking one? Mojca _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
