I would like to start by saying that i didn't claim my way was better. -) why https way No need to set up ssh keys. (so basicaly just lazyness from my part)
-) How do you update your fork with changes from origin to avoid a merge commit? Thanks for pointing this out. This is something i didn't take into account (and have probably pushed a merge commit a couple of times) There is a way using the --rebase option during the pull command though -) The readonly setting does indeed solve the accidental commits. -) Won't you have the same merge commits if there's been a lot of changes since you created your branch and want to pull in those changes before creating a pull request? -) When making a branch you could always create it from any chosen remote: git fetch -p upstream git checkout -b testupstreambranch upstream/master (where upstream is the remote you forked from) But you're right. Your suggested approach surely has some advantages, thanks for explaining them to me. Regards, Stefaan Dutry (sdutry) 2017-02-04 7:43 GMT+01:00 Lukasz Lenart <lukaszlen...@apache.org>: > 2017-02-03 20:19 GMT+01:00 Stefaan Dutry <sdu...@apache.org>: >> Personaly i can understand everything in there. > > Cool, thanks :) > >> However i tend to do things differently myself. >> >> How i usualy work: >> * I use clone with https way > > Why? > >> 1. Fork the repository to my own account >> 2. clone the repository localy, making my fork 'origin' (git clone >> <https-url (of the fork)>) >> 3. add the original repository as a remote with the name upstream (git >> remote add https://github.com/apache/struts.git) >> 4. create a branch for changes >> 5. do changes localy >> 6. add changed files (git add <changed files>) >> 7. commit changes localy (git commit -m "my comment explaining what >> changed") >> 8. push to origin (being my fork) (git push origin <branchname>) >> 9. create pull request > > How do you update your fork with changes from origin to avoid a merge commit? > >> Reasons for using own fork as origin: >> * When looking up commands i tend to always come across commands that >> push to origin >> * It tends to make it more awkward to accidently try to push to the >> original git repo > > Pushing just once with git push -u solves the problem but I understand > and that's why I'm preferring Github as the Apache Struts mirror is > readonly, you won't be able to push anything there :) > >> Spotted typo: >> Do you changes and commit them... >> => Do your changes and commit them ... >> >> I'm not saying either way is better, just thought i'd mention this >> slightly different approach. > > With proposed approach you are always starting off the master with up > to date version of source code, you don't have to update your fork and > there is no more merge commits. These are the advantages with proposed > flow but I'm open for discussion. > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
