A while ago I created a pull request to fix some issues with spaces in
filenames. At the time we decided to wait to see what happened with the
locationtech migration; however since that time I think it was decided
pull request could be accepted.
I added a few other minor fixes for the raster
The following pull request is ready:
- https://github.com/uDig/udig-platform/pull/144
- https://jira.codehaus.org/browse/UDIG-1934
Mentioned this yesterday but perhaps it was deep in an email thread (do not
want this pull request to go stale; as it is currently passing tests).
Emily are you in a
Okay Moovida caught up with me on IRC and we made some progress on this for you
Frank.
What we have here is BasicFeatureRenderer trying to solve one problem (clearing
a small area that needs and update) in the wrong section of code.
The Renderer API render(Graphics2D, ReferencedEnvelope, IProgr
So what was the story with this one?
--
Jody Garnett
On Tuesday, 3 April 2012 at 12:27 AM, Frank Gasdorf wrote:
> 2012/4/2 Jody Garnett (mailto:jody.garn...@gmail.com)>:
> > the split tool seems to have refresh issues
>
>
> I guess this could be a problem coming from my pull request last m
Hello all,
I was wondering if someone could please review a pull request I have
submitted.
https://github.com/uDig/udig-platform/pull/65
The updates I have made in this request include:
- Language fragments now compile and build correctly in Maven (with the
-Planguage profile enabled);
Thanks.
On 28/09/2011 3:35 PM, Jody Garnett wrote:
Looks like jesse got to it.
___
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
___
Looks like jesse got to it.
--
Jody Garnett
On Thursday, 29 September 2011 at 1:51 AM, Emily Gouge wrote:
> A few weeks ago I fixed a few minor uDig bugs and created a pull
> request. I'm wondering if somebody can review and merge these changes?
>
> https://github.com/uDig/udig-platform/pu
A few weeks ago I fixed a few minor uDig bugs and created a pull
request. I'm wondering if somebody can review and merge these changes?
https://github.com/uDig/udig-platform/pull/48
Thanks,
Emily
___
User-friendly Desktop Internet GIS (uDig)
http://u
So far it is going well details here:
- https://github.com/uDig/udig-platform/pull/44
There is also walkthrough 1 and 2 for more general feedback.
--
Jody Garnett
___
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://list
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 ch
Typically I make a branch for each change. But you can do the branch after
the fact. Basic idea:
git checkout -b branchName commitSha
git cherry-pick commitShaStart..commitShaEnd
Jesse
On Sun, Mar 6, 2011 at 8:48 AM, Jody Garnett wrote:
> Thanks jesse; that was a fairly smooth process - I w
Thanks jesse; that was a fairly smooth process - I was able to grab your change
from the branch and review it locally.
I do understand how you doing the work on a branch makes for a more stable
target for the merge request.
I am just worried about doing too many things at once and not being able
Just got the pull request message. It works.
Andrea
On Sun, Mar 6, 2011 at 7:38 AM, Jesse Eichar
wrote:
> Hi PMC
> Let me know if you do not get a pull-request from me sometime today. I have
> made the request in the UI, now it is just a matter of waiting for GitHub to
> send the notice.
> Jess
Hi PMC
Let me know if you do not get a pull-request from me sometime today. I have
made the request in the UI, now it is just a matter of waiting for GitHub to
send the notice.
Jesse
___
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions
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
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 n
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
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-re
18 matches
Mail list logo
