[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [udig-devel] Pull request rule
|
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
>
>