struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukasz Lenart <>
Subject Re: Documentation
Date Sat, 04 Feb 2017 06:43:12 GMT
2017-02-03 20:19 GMT+01:00 Stefaan Dutry <>:
> 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


> 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
> 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.

+ 48 606 323 122

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message