Hi,
so far I used Stefaan's aproach, too. I was not aware of the pulling/rebasing/merge-commit issues. Lukasz, would you add your explanation to the html page? IMHO seting up ssh keys is a big hurdle for newbies. I would recommend usage of https urls and just mention that there is the option to use ssh. Regards, Christoph > From: Lukasz Lenart <lukaszlen...@apache.org> > To: Struts Developers List <dev@struts.apache.org>, > Date: 04.02.2017 10:02 > Subject: Re: Documentation > > 2017-02-04 8:26 GMT+01:00 Stefaan Dutry <sdu...@apache.org>: > > I would like to start by saying that i didn't claim my way was better. > > Yes, I know that, don't get me wrong I just want to know if I am > missing something and maybe there is a better way :) > > > -) why https way > > No need to set up ssh keys. (so basicaly just lazyness from my part) > > Fair point, I will add optional https use > > > -) 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 > > But --rebase do a lot more harm when working with a remote branch, > it's a good option when used locally, but since you've pushed out your > branch you should avoid it > https://github.com/apache/struts/pull/58/commits > > > -) The readonly setting does indeed solve the accidental commits. > > That's why I prefer this way when working on large things, even if I > can push directly to Apache :) > > > -) 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? > > You don't have till your branch doesn't have conflicts with "master", > if you do have conflicts you must reverse merge "master" anyway. I > think this is the same with both approaches. > > > -) 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) > > Yes, that's true but you must remember about these extra params, with > my way "master" is always upstream/origin and branches are "forks" > > > But you're right. > > Your suggested approach surely has some advantages, thanks for > > explaining them to me. > > Cool, thanks for reviewing it and making fair points :) > > > 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 > This Email was scanned by Sophos Anti Virus
