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
