pull requests

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

pull requests

Post by mwieder » Sat Apr 13, 2013 11:45 pm

Is it still necessary to issue pull requests off master?

So I forked the repository on github.
I cloned the fork onto my computer.
I made a branch off master and checked it out.
I made my changes on my branch.
I checked out the master branch and pulled the latest changes from the 6.0.1 branch.

Should I now merge my changes back onto master before pushing and issuing a pull request?
Or can I push my changes on my branch and issue a pull request?

It seems like a bad idea to merge my changes while the 6.0.1 branch is still in flux in the livecode repository and haven't been merged into master there.

I think it would be good to have the procedure for issuing pull requests laid out simply so that contributors don't have confusion about how to go about things.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: pull requests

Post by monte » Sun Apr 14, 2013 12:55 am

Is it still necessary to issue pull requests off master?
I think so. Mark won't want to merge anything but bugfixes into a release branch.
So I forked the repository on github.
I cloned the fork onto my computer.
I made a branch off master and checked it out.
I made my changes on my branch.
I checked out the master branch and pulled the latest changes from the 6.0.1 branch.
Yeah... this is the trouble because Marks changes to 6.0.1 config enabled me to compile with 10.6 and so I branched off release to to resolveImage but then I knew he would want the pull request to branch of master head so I ended up copying my change, branching master head, pasting the change and then deleting the branch off release... I think once there's a develop branch in there that has changes merged off release onto it then things will be much simpler. Most of our stuff can then branch of develop.
Should I now merge my changes back onto master before pushing and issuing a pull request?
Won't your branch then include a merge of release onto master before it's ready for release? I think it would and that's not what Mark will want because master should only be merged with release when it's actually released...
Or can I push my changes on my branch and issue a pull request?
You should push your branch and issue a pull request of it to master or develop (when it exists) but because you've merged release it complicates things... Not sure if you can rebase on master from there... I tried that and it rebased release so I had to reset --hard.. you might be able to checkout master and cherry pick??? starting to get into the mysteries of git though...
It seems like a bad idea to merge my changes while the 6.0.1 branch is still in flux in the livecode repository and haven't been merged into master there.

I think it would be good to have the procedure for issuing pull requests laid out simply so that contributors don't have confusion about how to go about things.
I think the docs on the contributor page will eventually be clarified to cover this clearly.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: pull requests

Post by mwieder » Sun Apr 14, 2013 1:57 am

You should push your branch and issue a pull request of it to master or develop (when it exists) but because you've merged release it complicates things...
I merged the 6.0.1 branch onto my master branch, not onto my dev branch. My changes are still pristine.
Not sure if you can rebase on master from there... I tried that and it rebased release so I had to reset --hard.. you might be able to checkout master and cherry pick??? starting to get into the mysteries of git though...
Grrr. So I'm going to have to do a git reset --hard "6.0.0" on my master branch to undo the 6.0.1 pull, create a "release" branch, stage the 6.0.1 changes there instead of onto master, then merge my changes on my dev branch onto my master branch in order to issue a pull request.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: pull requests

Post by monte » Sun Apr 14, 2013 2:29 am

Grrr. So I'm going to have to do a git reset --hard "6.0.0" on my master branch to undo the 6.0.1 pull, create a "release" branch, stage the 6.0.1 changes there instead of onto master, then merge my changes on my dev branch onto my master branch in order to issue a pull request.
It's all getting a little confusing but if you branched your dev branch of release-6.0.1 then merging that into master will bring those changes over. If you wait until RunRev have merged release-6.0.1 with master then it doesn't matter because it's all in the same timeline. Hopefully once 6.0.1 is out Mark will create a dev branch off it which will be regularly updated with anything critical from release branches.

Also, don't merge to master to issue the pull request. Push your feature or bug fix branch to your fork on github then issue a pull request from that branch to the appropriate branch on runrev/livecode. For most things apart from regression fixes it should be develop (which doesn't exist). If you merge to master and they don't accept it then it makes your life hard because your master branch now can't cleanly pull theirs.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: pull requests

Post by mwieder » Sun Apr 14, 2013 2:45 am

Also, don't merge to master to issue the pull request.
Great. Thanks - that's why I was asking. I was under the assumption that I'd have to merge to master before pushing because that's the way they wanted the pull requests. Not doing that keeps things *much* cleaner.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: pull requests

Post by monte » Sun Apr 14, 2013 2:52 am

If you look at open pull requests they are all on their own branch: https://github.com/runrev/livecode/pulls

When (I'm assuming Mark) integrates them then I'd guess that they will decide for themselves which branch they want to merge them into given the change.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: pull requests

Post by mwieder » Sun Apr 14, 2013 3:39 am

I'm not too concerned about how they're handled at the project management end, I just want to make sure that I'm set up properly at the contributor end so that I don't end up rebranching and rebasing and who-knows-what-all-else in order to backtrack.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: pull requests

Post by monte » Sun Apr 14, 2013 3:56 am

right, in that case just always work on a branch named with the feature/bugfix you are implementing, push that to your fork then send a pull request from that. You can then always pull their branches from runrev/livecode without any trouble and rebase or merge your feature with the head of develop if they are taking a while to implement and you want the latest features...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: pull requests

Post by mwieder » Sun Apr 14, 2013 4:11 am

Good. That sounds straightforward.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: pull requests

Post by monte » Sun Apr 14, 2013 4:17 am

yep, that's why I like git-flow. It's also a well documented branching workflow and there's scripts and support in GUI tools like SourceTree for it. It would be well worth just following it to the letter rather than coming up with a variant I think.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: pull requests

Post by LCMark » Sun Apr 14, 2013 11:37 am

Basically, as Monte says, work in a branch off of master, or in the future if you are working on a feature (or bugfix) which is 'for the future' (i.e. beyond the current dev cycle for the next major version) branch off of development and track.

The issues at the moment sound like they are more to do with the teething issues with the build scripts rather than anything else - these will drop away when 6.0.1 gets merged into master - which we're hoping for in a few days.

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: pull requests

Post by LCMark » Sun Apr 14, 2013 2:26 pm

I should point out that the docs we have posted so far (i.e. the getting involved document) do need some significant revisions. We'll be doing those over the course of the next week - now that the project is out and there are people getting involved we can see better how to structure and organise things.

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3581
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: pull requests

Post by mwieder » Sun Apr 14, 2013 4:34 pm

Yeah, I posted revised "getting started" updates to the dev-list yesterday.

Locked

Return to “Engine Contributors”