[IPython-dev] Moving to git/github

[Fernando Perez]

Hi Erik,

On Wed, Apr 14, 2010 at 11:46 AM, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> As a "casual" developer/power user of ipython, I have something to add here...

Thanks a lot for your feedback!

>> So I don't see a compelling reason to go to hg, despite the fact that
>> I'm sure it's a perfectly good tool.  I do like the fact that hg is
>> there and is good, I have the impression that the competition between
>> hg and git is benefiting both projects and they are learning from each
>> other.
>
> There is one compelling reason to choose hg over git: simplicity.  My
> experience between bzr, hg, and git has been that they are in exactly
> that order of increasing complexity... but hg and bzr are both *way*
> easier than git.  Frankly, it shows that git was written by someone
> who wrote the linux kernel - yes you can do a lot of things, but the
> simplest of things are just more complicated or have surprising
> gotchas.  The hg<->git bridge makes things easier, but the times I've
> used it, it seems to negate all the advantages of hg or git (speed
> and/or the advanced features), although that's only based on a couple
> data points.  And anyway, if the goal is simplicity, adding an
> additional conceptual layer is far worse than taking a few-percent
> speed hit.
>
> Now given that ipython is a somewhat "low-level" utility in that it
> seems rather difficult to just do some quick hacks on without really
> understanding what's going on, maybe this isn't an issue, as maybe all
> the core devs are fine with a more complex system... but git would
> certainly be a barrier to someone like me contributing.

I really hope that git does not become a barrier to you nor anyone
else.  I think git is improving, and that part of the problem with git
is that a lot of the existing documentation exposes all of its
flexibility (and hence complexity) up front.  The man pages (I'll be
the first to admit) are very opaque, and a few choices of the
interface are downright wrong (for commit, -a *should* have been the
default like everywhere else, and --some-option should be used to only
commit manually staged changes).  But things do get better (e.g. the
new --set-upstream in 1.7 which is like bzr's great --remember for
push/pull).

I do take your comment to heart though (esp. since the same issue is
about to hit us on ipython, matplotlib and nipy!).  I am personally
committed to writing up a *clear* workflow document for ipython/nipy
that can be followed nicely by anyone who starts by:

- getting the sources for ipython via version control
- from there, makes a small change to fix/improve something
- then, wants to share that change with minimal effort.

The key will be, I think, not to point people to multiple tutorials
they can read and then assemble things in their head, but instead to
give them *our workflow*, with all the choices explicitly indicated
and made for them.  Once they learn more about git they can change
those decisions and lay their workflow differently if desired, but
initially they have no criterion of their own to choose, so we might
as well pick good choices for them to let them get up and running
without much pain.

So I'm not discounting your comment, I just hope that for ipython,
nipy and others I'm involved with, we'll be able to provide a clear
enough guide that git's extensive flexibility is not an upfront
hindrance to anyone.  We'll see if we succeed :)

>> It's true that it's a little annoying to use all systems, but
>> hopefully soon we'll be down to hg and git: I don't see bzr going
>> anywhere, and git-svn is a pretty good option to use for svn repos
>> once you're familiar with git.  And as those two converge even
>> further, it should get even easier.
>
> I personally use bzr for all of my projects that I have a choice in
> the matter... I think it's not at all clear-cut that bzr is going to
> disappear any sooner than hg or git unless Canonical and Ubuntu
> disappear - they're committed to launchpad and it is very closely tied
> to bzr - a lot of people will stick with it for exactly those reasons.
>  That's certainly not a reason to stick with bzr if most of the
> ipython devs aren't happy with it, but it's not fair to say it's dying
> by any stretch.

I said 'not going anywhere', not 'disappear'.  I simply don't see
major bzr uptake in new projects, and I do see people moving away from
it (anecdotal evidence from blog posts, no statistical study here :),
so I don't see it growing significantly, especially with the rapid
rise in popularity of hg/git.  But with the weight of LP/canonical and
other existing projects behind it, I'm sure it will remain viable for
those who like it (and I hope it will continue to improve, its
developers have certainly been super-friendly to me on irc and for
that I thank them profusely).

> I'd also add that it looks like you're using the pack-0.92 format...
> the more recent 2a format works quite a bit faster in my experience,
> and I've never had any conversion problems...

The conversion is ongoing right now at LP, so hopefully it will finish
soon and we'll have all repos on 2a, to ease the transition.

Cheers,

f