Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Georg Brandl
This is now a moot point, but with generaldelta (active by default in hg 3.7) the hg clone size is at around 400 MB. Georg On 01/04/2016 11:53 PM, Alex Gaynor wrote: > My git clone is 350MB (after a make clean), a fresh hg clone is 650MB. > > Alex > > On Mon, Jan 4, 2016 at 5:38 PM, Georg Brand

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Serhiy Storchaka
понеділок, 04-січ-2016 15:33:51 R. David Murray написано: > (Oh, and let me mention this while I'm thinking about it: we're going > to have to do some extra work to make the hash links work in the bug > tracker, since I don't think there's any a priori way to distinguish > between hg hashes and git

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Serhiy Storchaka
понеділок, 04-січ-2016 21:18:39 Brett Cannon написано: > On Mon, 4 Jan 2016 at 13:14 Donald Stufft wrote: > > On Jan 4, 2016, at 4:11 PM, Brett Cannon wrote: > > It’s pretty easy to migrate the entire history (at least what’s in Hg) > > including all branches and tags. > > It's not about the dif

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Senthil Kumaran
On Mon, Jan 4, 2016 at 2:56 PM, Brett Cannon wrote: > I'm not sure, which is why I'm asking what difference it would make if we > separated out Python 2 branches into their own clone from Python 3 branches. Irrespective of the size difference, separating Python2 repo from Python3 repo might be

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Serhiy Storchaka
понеділок, 04-січ-2016 09:49:57 Eli Bendersky написано: > I suppose you'll want to use https://github.com/python/cpython, which I'm > currently maintaining as a read-only mirror. Let me know when you want to > take control of that repo - I think since it belongs to the "python" Github > org already

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Ezio Melotti
On Tue, Jan 5, 2016 at 7:38 AM, Nick Coghlan wrote: > On 5 January 2016 at 11:33, R. David Murray wrote: >> On Tue, 05 Jan 2016 01:26:58 +, "Gregory P. Smith" >> wrote: >>> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray >>> wrote: >>> >>> > to have to do some extra work to make the hash l

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Nick Coghlan
On 5 January 2016 at 11:33, R. David Murray wrote: > On Tue, 05 Jan 2016 01:26:58 +, "Gregory P. Smith" > wrote: >> On Mon, Jan 4, 2016 at 12:34 PM R. David Murray >> wrote: >> >> > to have to do some extra work to make the hash links work in the bug >> > tracker, since I don't think there'

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Ezio Melotti
The linkifier converts old svn revision numbers to links to e.g. https://hg.python.org/lookup/r12345 , and this figures out the equivalent hg changeset and redirects to the corresponding hg.p.o page. The linkifier should just create links to https://hg.python.org/lookup/csid and let the page figure

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Alex Gaynor
Probably the easiest thing is to point the linkifier at our own webservice that just does: if hash not in cache: try: requests.head("github.com/hash") except requests.error: try: request.head("hg.python.org/hash") except request.error: re

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread R. David Murray
On Tue, 05 Jan 2016 01:26:58 +, "Gregory P. Smith" wrote: > On Mon, Jan 4, 2016 at 12:34 PM R. David Murray > wrote: > > > to have to do some extra work to make the hash links work in the bug > > tracker, since I don't think there's any a priori way to distinguish > > between hg hashes and g

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Gregory P. Smith
On Mon, Jan 4, 2016 at 12:34 PM R. David Murray wrote: > to have to do some extra work to make the hash links work in the bug > tracker, since I don't think there's any a priori way to distinguish > between hg hashes and git hashes. > Just ignore the remote possibility of short 32-bit hash prefi

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Trent Nelson
On Mon, Jan 04, 2016 at 07:09:30PM -0500, Donald Stufft wrote: > > > On Jan 4, 2016, at 7:06 PM, Trent Nelson > > wrote: > > > > They’re very rough notes but may prove useful. Should *hopefully* > > be repeatable. One issue I noticed after the fact is that a couple > > of the renames that happ

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Donald Stufft
> On Jan 4, 2016, at 7:06 PM, Trent Nelson wrote: > > Hey Brett, all, > > I’m playing a bit of catch-up with e-mail, but it occurred to me some of the > work I did getting PyParallel switched over to github could be of benefit. > First thing that comes to mind is this wiki page where I tried to

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Trent Nelson
Hey Brett, all, I’m playing a bit of catch-up with e-mail, but it occurred to me some of the work I did getting PyParallel switched over to github could be of benefit. First thing that comes to mind is this wiki page where I tried to capture the steps I used for the conversion and subsequent keepi

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Brett Cannon
On Mon, 4 Jan 2016 at 14:09 Guido van Rossum wrote: > On Mon, Jan 4, 2016 at 1:50 PM, Donald Stufft wrote: > >> I'm not sure that you'd see much savings. You'd only get deltas that were >> never merged to master excluded. Point taken though. >> > > Is the expectation that a Git clone would be si

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Alex Gaynor
My git clone is 350MB (after a make clean), a fresh hg clone is 650MB. Alex On Mon, Jan 4, 2016 at 5:38 PM, Georg Brandl wrote: > On 01/01/2016 08:24 PM, Brett Cannon wrote: > > If you want to read the reasons I chose GitHub over GitLab, > > see > https://mail.python.org/pipermail/core-workflow

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Georg Brandl
On 01/01/2016 08:24 PM, Brett Cannon wrote: > If you want to read the reasons I chose GitHub over GitLab, > see https://mail.python.org/pipermail/core-workflow/2016-January/000345.html . > If you want to discuss the decision or help with the transition, please > subscribe to the core-workflow maili

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Barry Warsaw
On Jan 04, 2016, at 02:09 PM, Guido van Rossum wrote: >I currently often rely on a single Hg clone containing all branches. I do hope that a single repo will contain all the branches, though I wouldn't mind too much if we split Python 2 and 3 into separate repos. git worktree is a nice tool if y

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Guido van Rossum
On Mon, Jan 4, 2016 at 1:50 PM, Donald Stufft wrote: > I'm not sure that you'd see much savings. You'd only get deltas that were > never merged to master excluded. Point taken though. > Is the expectation that a Git clone would be significantly larger than an Hg clone of an equivalent repo? I cu

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Donald Stufft
I'm not sure that you'd see much savings. You'd only get deltas that were never merged to master excluded. Point taken though. Sent from my iPhone > On Jan 4, 2016, at 4:18 PM, Brett Cannon wrote: > > > >> On Mon, 4 Jan 2016 at 13:14 Donald Stufft wrote: >> >>> On Jan 4, 2016, at 4:11 PM,

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Brett Cannon
On Mon, 4 Jan 2016 at 13:14 Donald Stufft wrote: > > On Jan 4, 2016, at 4:11 PM, Brett Cannon wrote: > > > > On Mon, 4 Jan 2016 at 13:08 Steve Dower wrote: > >> I've found that hggit works very well - I used it to migrate my work >> project to github and still use it to avoid having to deal wit

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Donald Stufft
> On Jan 4, 2016, at 4:11 PM, Brett Cannon wrote: > > > > On Mon, 4 Jan 2016 at 13:08 Steve Dower > wrote: > I've found that hggit works very well - I used it to migrate my work project > to github and still use it to avoid having to deal with git. (My intent i

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Brett Cannon
On Mon, 4 Jan 2016 at 13:08 Steve Dower wrote: > I've found that hggit works very well - I used it to migrate my work > project to github and still use it to avoid having to deal with git. (My > intent is to keep using it for Python as well.) > > Is the plan to migrate the entire history or just

Re: [python-committers] We will be moving to GitHub (hopefully) in2016

2016-01-04 Thread Steve Dower
I've found that hggit works very well - I used it to migrate my work project to github and still use it to avoid having to deal with git. (My intent is to keep using it for Python as well.) Is the plan to migrate the entire history or just master? Top-posted from my Windows Phone -Original

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Alex Gaynor
+1 Alex On Mon, Jan 4, 2016 at 4:07 PM, Donald Stufft wrote: > > > On Jan 4, 2016, at 3:51 PM, Barry Warsaw wrote: > > > > I once looked at it and decided it wasn't something I wanted to touch ;) > so > > paying Eric to do it might not be a bad idea. > > > I’d prefer it if we didn’t financiall

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Donald Stufft
> On Jan 4, 2016, at 3:51 PM, Barry Warsaw wrote: > > I once looked at it and decided it wasn't something I wanted to touch ;) so > paying Eric to do it might not be a bad idea. I’d prefer it if we didn’t financially support ESR since he likes to spout off racist and misogynistic garbage. I’m

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Barry Warsaw
On Jan 04, 2016, at 03:33 PM, R. David Murray wrote: >Maybe The PSF could fund Eric Raymond to do this? reposurgeon is the tool he developed to port Emacs's bzr repository to git, and it successfully handled all the previous vcses Emacs was ever developed under (after, IIRC, much tweaking). http

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread R. David Murray
On Mon, 04 Jan 2016 18:18:02 +, Brett Cannon wrote: > On Mon, 4 Jan 2016 at 09:50 Eli Bendersky wrote: > > > > I have to admit that I'm not a big expert on Mercurial --> Git converters > > and the way I maintain this mirror may not be the best approach, so I > > encourage you folks to find a

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Brett Cannon
On Mon, 4 Jan 2016 at 09:50 Eli Bendersky wrote: > On Fri, Jan 1, 2016 at 11:24 AM, Brett Cannon wrote: > >> If you want to read the reasons I chose GitHub over GitLab, see >> https://mail.python.org/pipermail/core-workflow/2016-January/000345.html . >> If you want to discuss the decision or hel

Re: [python-committers] We will be moving to GitHub (hopefully) in 2016

2016-01-04 Thread Eli Bendersky
On Fri, Jan 1, 2016 at 11:24 AM, Brett Cannon wrote: > If you want to read the reasons I chose GitHub over GitLab, see > https://mail.python.org/pipermail/core-workflow/2016-January/000345.html . > If you want to discuss the decision or help with the transition, please > subscribe to the core-wor

Re: [python-committers] Github accounts

2016-01-04 Thread Andrew MacIntyre
On 4/01/2016 12:38 AM, M.-A. Lemburg wrote: On 03.01.2016 05:19, Guido van Rossum wrote: This hardly seems like a real problem, so let's not worry more about it until someone actually needs help solving this. For Andrew, it would have been a real problem, so IMO it's better to be prepared for