Good to know. With the way our commit policies are structured today (and
these are naturally heavily influenced by the old svn model) github pull
requests are really only going to be useful for people who don't have
commit access / push rights to the canonical repository. Its a much handier
workflo
If (part of) the motivation for encouraging developer forks is to allow the
use of Github pull requests then I think I should point out that Github
allows pull requests within the same repository now (no forks necessary.)
They didn't when they first introduced pull requests. See
https://help.github
I updated the wiki so we have a landing page for the 9.x stream, and shuffled
the recently completed proposals into the correct location:
- http://docs.codehaus.org/display/GEOTOOLS/Home
- http://docs.codehaus.org/display/GEOTOOLS/Proposals
> The 8.x branch has been cut.
>
> https://github.co
On Tue, Jul 3, 2012 at 9:00 AM, Jody Garnett wrote:
> Aside: I don't think I yet fully comprehend the purpose of our
> developer forks. I'm using "Pro Git" as my reference book and its
> discussion of alternative work-flows for projects, developer forks are
> only mentioned in the context of very
On 03/07/12 15:00, Jody Garnett wrote:
>> Apologies for so many entry-level questions.
> bah - no apologies - we need entry level questions so we can continue to
> beat answers out of justin.
+1.
My inbox is currently full of emails that constitute A Compilation of
the Git Wisdom of Justin.
(My
> Aside: I don't think I yet fully comprehend the purpose of our
> developer forks. I'm using "Pro Git" as my reference book and its
> discussion of alternative work-flows for projects, developer forks are
> only mentioned in the context of very restricted access to the
> canonical repo, ie. I woul
Thanks Justin - that's clear.
If I want to sync my fork with branches that are newly created in the
canonical repo I would do:
git fetch geotools # to get refs to new branches
git checkout new_branch_name
git push mbedward new_branch_name
Is that right ?
Aside: I don't think I yet fully compre
Hey Michael,
Again this is personal preference as there a few ways to do it (basically
how you want to organize your remotes) but when i want to update the
primary branches in my fork here is what i do:
% git checkout master
% git pull geotools master
% git push jdeolive master
% git checkout 8.
Hi Justin,
is there a recommended work-flow for keeping our developer forks in
sync with the canonical branches ?
Michael
On 3 July 2012 11:09, Justin Deoliveira wrote:
> Hi all,
>
> The 8.x branch has been cut.
>
> https://github.com/geotools/geotools/tree/8.x
>
> And along with it.
>
> h
Hi all,
The 8.x branch has been cut.
https://github.com/geotools/geotools/tree/8.x
And along with it.
https://github.com/geotools/geotools/tree/rel_8.x
I have also run through the paces of generating out the 8.0-RC2 release,
fixing issues that resulted from the git changeover along the way
10 matches
Mail list logo
