Re: [udig-devel] Pull request rule

[andrea antonello <andrea.antonello@xxxxxxxxx>]

I just made the merge and wanted to add the thing to the workflow in
the new git doc svg.
Jesse, can you check? I chose to pursue option 2:

1) create a local branch for my remote one:
git branch local/udig-platform-remote/master remotes/udig-platform-remote/master

2) switch to that branch:
git checkout local/udig-platform-remote/master

3) merge in the pull request changes
git pull https://moovida@xxxxxxxxxx/moovida/uDig.git

-> here the docs say to add also the tagname at the end, but that
didn't work for me. Any idea?
That is important, becuse if I had pushed further changes to my clone,
they would have been pulled.

4) push the thing up that branch:
git push

That's it. And it worked, still that tag of num 3 to check.

Ciao,
Andrea






On Sun, Mar 6, 2011 at 7:37 AM, Jesse Eichar
<jesse.eichar@xxxxxxxxxxxxxx> wrote:
> You are kind of missing my point.  The point is when you have your own git
> repository and you want to make a pull-request (in gitorious terms a merge
> request).  You should not make the request from a live branch.  IE master.
>  Here is a possible workflow:
> 1.  Make changes
> 2.  Make tag Foo
> 3.  Push Tag to github:  git push myRepo Foo
> 4.  In Github WebUI, switch to Foo
> 5.  Make Pull-Request
> That is all I am saying.  After this point you should not make changes to
> tag Foo.  As an extension to my point Foo could be a branch as long as you
> do not change it after making pull-request.
> To finish my workflow
> 6.  Wait for request to be merged into uDig repository
> 7.  delete tag from your repository:  git push myRepo :Foo
> Hope that is clearer
> Jesse
> On Sat, Mar 5, 2011 at 11:47 PM, Jody Garnett <jody.garnett@xxxxxxxxx>
> wrote:
>>
>> I still have the article you sent in mind:
>> - http://nvie.com/posts/a-successful-git-branching-model/
>> What you describe does seem in keeping with this idea. One thing I like in
>> that model is the concept of a
>> "release branch" so that all the QA and bug fixes (ie polish) that go into
>> a release do not disrupt master in the event a point release needs to be
>> made in a hurry.
>> --
>> Jody Garnett
>>
>> On Sunday, 6 March 2011 at 8:42 AM, Jody Garnett wrote:
>>
>> I am not sure what to think Jesse. We can of course add more instructions
>> to the "how to take part" page for uDig. It is just that I am not very
>> comfortable with git yet; and I do not see the point of having my own master
>> if I am still going to work on a branch?
>> I do see what you are saying; is there any way to work on my master; and
>> then put the work aside on a branch? Perhaps that is what you are describing
>> and I just do not know the details...
>>
>> --
>> Jody Garnett
>>
>> On Sunday, 6 March 2011 at 5:26 AM, Jesse Eichar wrote:
>>
>> Hi,
>> I would like to add a new rule about how to handle pull requests.  All
>> pull requests should be based on a branch or a tag rather than your master.
>>  The reason being if it is on a branch (or a tag) then you are less likely
>> to do more work on that branch/tag and make it hard to merge the
>> pull-request.
>> Consider this scenario.
>> 1.  You make a change
>> 2.  You make a pull request
>> 3.  Time passes and we haven't had time to merge it
>> 4.  You make more changes to the branch (master for example) but the
>> changes are not ready to be merged
>> 5.  We review your pull request and like it and want to merge it
>> 6.  We do a git pull yourRepo master
>> 7.  All changes to the branch are merged including the ones that are not
>> part of the pull-request
>> At step 7 we should notice the mistake but likely we won't eventually and
>> thus we might merge the incorrect commits.
>> Thus rule.
>> 1.  Make a tag (or branch) when you have the commits ready
>> 2.  Push tag (or branch) to github:  git push myRepo tagname
>> 3.  Go to github and select the tag (branch)
>> 4.  Make pull-request
>> 5.  After we have merged pull-request delete tag:  git push myRepo
>> :tagname
>> To delete a tag or branch you use the same push command as you would for
>> pushing a tag or branch but add a : at the start of the tagname.  Don't ask
>> me why a colon, I don't know, but that is how to do it.
>> Jesse
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>
>>
>>
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>