struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefaan Dutry <sdu...@apache.org>
Subject Re: Documentation
Date Sat, 04 Feb 2017 07:26:35 GMT
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 <lukaszlenart@apache.org>:
> 2017-02-03 20:19 GMT+01:00 Stefaan Dutry <sdutry@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message