ANN: moving to github
jason pellerin
github. Our new home is here:
https://github.com/nose-devs/nose
I'll convert the google code repo to git this week, and then try to
figure out how to move the issues over.
JP
Kumar McMillan
As discussed over the past few weeks, nose development is moving to
github. Our new home is here:
https://github.com/nose-devs/nose
I'm excited about this! Thanks for kicking it off.
I'll convert the google code repo to git this week, and then try to
figure out how to move the issues over.
fwiw, I think migrating google code to git is priority #1 so we can keep them in sync and move development forward. I see you already started moving issues over which we'll need eventually.
The Google Code wiki leaves a lot to the imagination on how to migrate from Mercurial to git: http://code.google.com/p/support/wiki/GitFAQ
I guess we have to click the reset button, switch it to git, then push the new git repo?
JP
--
You received this message because you are subscribed to the Google Groups "nose-dev" group.
To post to this group, send email to nose...@googlegroups.com.
To unsubscribe from this group, send email to nose-dev+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nose-dev?hl=en.
jason pellerin
> fwiw, I think migrating google code to git is priority #1 so we can keep
> them in sync and move development forward. I see you already started moving
> issues over which we'll need eventually.
Yeah. Mostly they moved ok, except all comments are now attributed to
me instead of the original author, and all issues are assigned to me,
and all patches disappeared. For the patches, what I've been doing is
making a gist with the patch contents and linking that in a comment on
the github issue, then closing the matching google code issue.
Laborious but I'm not sure how else to do it. There are about 60 left
to do.
> The Google Code wiki leaves a lot to the imagination on how to migrate from
> Mercurial to git: http://code.google.com/p/support/wiki/GitFAQ
>
> I guess we have to click the reset button, switch it to git, then push the
> new git repo?
It's pretty unclear. Unfortunately it looks like hg-git chokes on nose
so I think reset, convert and push is probably the only option. Is
there a reason to keep the current wiki pages, do you think?
JP
Thomas Kluyver
fwiw, I think migrating google code to git is priority #1 so we can keep them in sync and move development forward.
Thomas
Kumar McMillan
>Yeah. Mostly they moved ok, except all comments are now attributed to
me instead of the original author, and all issues are assigned to me,
and all patches disappeared. For the patches, what I've been doing is
making a gist with the patch contents and linking that in a comment on
the github issue, then closing the matching google code issue.
Laborious but I'm not sure how else to do it. There are about 60 left
to do.
We could just link to the old issue to view the patch though, right? If we close old issues with resolution "moved" or something then they won't be visible in the tracker but still accessible with a URL.
It's pretty unclear. Unfortunately it looks like hg-git chokes on nose
so I think reset, convert and push is probably the only option. Is
there a reason to keep the current wiki pages, do you think?
No reason I can think of. Having a wiki there is confusing anyway since that info is mostly duplicated in the docs.
K
Kumar McMillan
Hmm, I suppose we could just keep Google Code in Mercurial, delete all files and put a readme file explaining the new [converted] repo lives on git.
That might also preserve the existing development forks on GC which we may want to reference. Or not?
jason pellerin
<kumar.m...@gmail.com> wrote:
>
>
> On Wed, Dec 14, 2011 at 1:02 PM, Thomas Kluyver <tak...@gmail.com> wrote:
>>
>> On 14 December 2011 18:06, Kumar McMillan <kumar.m...@gmail.com>
>> wrote:
>>>
>>> fwiw, I think migrating google code to git is priority #1 so we can keep
>>> them in sync and move development forward.
>>
>>
>> I may be missing something, but why would we need two locations for the
>> public repository? I imagine it will just add complexity, because you have
>> to make sure both are up to date.
>
>
>
> Hmm, I suppose we could just keep Google Code in Mercurial, delete all files
> and put a readme file explaining the new [converted] repo lives on git.
That seems like a better idea than keeping two repos in sync. I'll do
that now, for the google code and bitbucket forks.
JP