Transition to git and github

[spyder-bot]

From jfilippi...@gmail.com on 2014-07-28T17:43:22Z

This is a suggestion that most probably has already been considered, but I would like to strongly recommend it. The reasons are:

1. git is faster and more flexible than hg (e.g., branching, history editing, staging to filter changes into smaller commits). I used hg for some years, then switching to git enabled much better and efficient version control. https://github.com/frej/fast-export 2. github interface ergonomics and popularity (that also contributes to the former) cannot be compared to bitbucket. So besides the benefit for the core developers themselves, the project will most likely receive much more support there, pull requests and active forks. http://www.takipiblog.com/2014/05/21/bitbucket-vs-github-its-more-than-just-features/ 3. issue tracking is superb on github and you will have one place for everything, not 2 sites (googlecode and bitbucket if I'm not missing something).
2. many other major projects have transitioned from googlecode to github over the past years.

Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1911

[spyder-bot]

From contrebasse on 2014-07-31T04:04:07Z

It was discussed when swithcing from googlecode to bibucket. The main reason for not swithching to git is that the core developers prefer mercurial. https://groups.google.com/forum/#!searchin/spyderlib/github/spyderlib/F0N3MdUNEtA/cP1DmEmibssJ There is a previous discussion I just discovered: https://groups.google.com/forum/#!searchin/spyderlib/github/spyderlib/z4JrnmAE3rA/oPUp8_Y8hI0J I personnaly prefer git and github, but I'm quite happy to contribute using bitbucket! The separation of the code and the issues is a problem though.

[spyder-bot]

From jfilippi...@gmail.com on 2014-08-01T10:49:54Z

Thank you for linking to the relevant discussions. I will try to find the time to read the arguments there and potentially we can revisit the matter.

[spyder-bot]

From ccordoba12 on 2014-08-01T11:15:45Z

I really like hg better, but here are my answers to your points:

1. We are a small project, so I don't see speed as a priority.
2. Github also has its shortcomings, e.g. I prefer to have issues and pull requests separate, and Bitbucket let us to have threaded talks too. Besides, if people wants to contribute they'll find their way to do it. There hasn't been a potential contributor that has complained about not using Github.
3. Issue tracking is one the most criticized aspects of Github. Google code is easier to handle (at least for me, which by far I'm its main user). The only problem is it doesn't allow markdown.
4. So? Others have migrated to Bitbucket and to SourceForge too.

Summary: Transition to git and github (was: transition to git and github)

[spyder-bot]

From ccordoba12 on 2014-08-23T14:03:52Z

I'd say that unless you put the time and effort to do the migration yourself, this is not going to happen anytime soon, sorry.

[spyder-bot]

From jfilippi...@gmail.com on 2014-09-06T01:24:35Z

Sorry for the delay in answering, but I wanted to first read the threads posted by @-contrebasse.

1. I did read the discussion on comparing git and hg. I won't try to compare them here, I think they are incomparable: hg cannot do the things that git can. I do understand that switching to git might look difficult for hg users. As I said, I was using hg for years and switching to git at first didn't make sense - until you understand why git works as it does and what you can do if you use that power. Perhaps it has a steep learning curve, but it is worth the effort. But one needs to work with it for some time before dismissing it. Just comparing the command names and concluding that hg does the same things in an easier way doesn't really cover it.

   Regarding GUIs, yes I also used TortoiseHg on windows for viewing changes, though I never issued actions from within a GUI, only from the command line. Currently I work on OS X and GitX is a pretty good interface for reviewing changes and filtering what is going to be staged. GitHubs's own interface is fair enough and it also works on windows, for people that prefer a GUI.

   Staging, branching, amending, and rebasing have more or less changed my development efficiency, so I would say that git helps not just to do what is possible with hg, but learn what else could possibly be done.

2. Issues and pull requests are separate on GitHub, or I don't understand what the comment means. Yes, pull requests do have an issue number (this is quite convenient), but they are listed in a different pane. And the filtering power available on github probably doesn't compare to any other similar website.

I don't know about threaded talks, I think github's linear issues are much better to follow and revisit a long time later. Threaded conversations are for mailing lists, not for public issues.

There hasn't been a contributor that has complained yet because they just dismissed they idea w/o discussing it, or they didn't even consider it in the first place. The reason is that many contributors are people who will send misc pull requests because they happened to find (and fix) a bug, or implement some small new feature. They do not plan to make a big commitment: if it already fits their workflow (git, github etc), then they will send it, otherwise they may as well be discouraged. Also, there are the major contributors to the core scientific python projects (numpy, scipy, matplotlib, ipython, networkx,...). The fact that they are on github and using git minimally tells us that they approve of that approach better, and may prefer to not contribute in another way. Attracting them will be a benefit. Dismissing the implications of their decision to use github is not easy, and cannot be based on comparing only hg to git, or bitbucket to github.

1. I haven't used issue tracking on GoogleCode, but I'm not aware of anyone who has criticized GitHub's interface - the opposite. I find GitHub's issues interface very convenient and efficient. I like Markdown very much and the ability to link to specific commits by just pasting the commit hash, and to link even to specific lines in code at specific commits has proved instrumental for me.
2. I am working on a project ( https://github.com/tulip-control/tulip-control ) which we previously had on sf (it still has a page there for the downloads). Sf is a pain to use. I was using BitBucket before using GitHub, when I used hg (several years ago). It didn't compare to GitHub. Still, whenever I go to any project that has its page on BitBucket, it takes me a long time to find what I want to look at, and may times I discover that what I want simply doesn't exist as BitBucket functionality. The fact that so many projects are on GitHub and not Bitbucket (and also: which projects) should make a good argument on its own. Not in terms of what is popular, but what proves more practical for people to use.

[spyder-bot]

From jfilippi...@gmail.com on 2014-09-06T01:34:34Z

From what I find there already is a synced mirror on github here: https://github.com/spyder-ide/spyderlib-mirror and an older experiment here: https://github.com/ccordoba12/spyder By migration do you mean transfer all the issues, or just convert the repository (which is trivial with hg-fast-export) ?

I would be happy to convert the repo itself (although I guess that is not what you refer to). About the issues, I could try: https://github.com/arthur-debert/google-code-issues-migrator (or maybe instead: http://trentm.com/2012/03/google-code-to-github.html )
I do not have the time to transfer the issues manually.

I don't think though that the issues need to be transferred. It may be better to move the code there, and direct there for opening new issues, while issues here are being closed. This will make the move smoother. I understand that cross-referencing may be somewhat inconvenient for old issues, but you can still simply link to them. Also, if the script linked above is actually used and proves functional (from its popularity I expect it will), then cross linking should work fine.

And I'm sure there will exist some straightforward solution to edit git history so that any commit messages referring to hg commit hashes are replaced with the git commit hashes (this concern was mentioned somewhere in the discussions linked above).

[spyder-bot]

From ccordoba12 on 2014-09-06T08:42:09Z

I was the first one to propose we should move to Github about 3 years ago. Since at that time my proposal was dismissed, I got more and more accustomed to hg and now I'd find really hard to do the switch :)

However, I find some of your reasons valid:

1. Being closer to the other projects of the Python Scientific stack, so we can all collaborate better.
2. Github interface is better.
3. Branching is easier with git.
4. Github for Windows/Mac seems good enough. On Linux there are git-cola and qgit, which I already use to contribute to IPython.

So please bring this issue to the mailing list to see what other people think about it. The only thing that worries me a bit is doing another transition in less than a year, which could be quite confusing for users and contributors alike.

[spyder-bot]

From jfilippi...@gmail.com on 2014-10-01T23:04:33Z

Thank you. The suggestion seems to be supported also by others, based on the suggestion in: https://groups.google.com/forum/#!topic/spyderlib/VH6SRGYwt-E The transition should not be very difficult, in particular if the old issues remain on googlecode and any new issues are redirected to github.

In any case I run a small experiment, transferring the first 35 issues from googlecode to github: https://github.com/johnyf/spyder_experiment/issues?q=is%3Aissue+is%3Aclosed using this python script that was cited also earlier above: https://github.com/arthur-debert/google-code-issues-migrator Some helpful other remarks can be found on this blog: http://trentm.com/2012/03/google-code-to-github.html

[spyder-bot]

From ccordoba12 on 2015-02-08T11:33:52Z

Labels: MS-v2.3.3

[ccordoba12]

This has been done, as you can see ;-)

[SylvainCorlay]

Oh yeah. Thank you so much for this. New contributions coming soon.

[ccordoba12]

@SylvainCorlay really great to know!!