Project

General

Profile

Actions

Misc #10547

closed

How to move the ruby project to git

Added by sytse (Sytse Sijbrandij) about 10 years ago. Updated almost 6 years ago.

Status:
Rejected
[ruby-core:66479]

Description

I'm posting this on the bugtracker as suggested by Koichi, feel free to move or close this if I've posted in the wrong project.

During rubyconf 2013 I briefly discussed the migration of ruby from svn to git with the core team. During the Q&A of Rubyconf 2014 Matz again mentioned that the community wants this and there are two problems that need to be solved:

  1. Incremental numbering
  2. Running scripts

I love ruby a lot and it is the reason I learned programming and became a developer. I now am CEO of GitLab B.V., we make open source software to collaborate on code.

The two problems are things that we can solve in GitLab:

  1. Make a project service that tags each commit on master incrementally.
  2. Scripts are easy to run on your own GitLab server, see http://doc.gitlab.com/ce/hooks/custom_hooks.html

If the ruby core team is interested we can make 1. and set up a GitLab server, convert the existing scripts and help maintain it for free.

If the core team wants to move to GitHub or Bitbucket we are also willing to help with scripting and conversion.

Best regards,
Sytse Sijbrandij
CEO GitLab B.V.


Related issues 3 (0 open3 closed)

Related to Ruby master - Feature #11741: Migrate Ruby to Git from SubversionRejectedActions
Related to Ruby master - Feature #14551: What's missing to switch to Git instead of using Subversion?Rejectedhsbt (Hiroshi SHIBATA)Actions
Related to Ruby master - Misc #14632: [ANN] git.ruby-lang.orgClosedhsbt (Hiroshi SHIBATA)Actions

Updated by shyouhei (Shyouhei Urabe) about 10 years ago

I have to say sorry about this: matz do not understand the situation. The situation is that no one in ruby-core is actively willing to do any dirty work to get things move to git. I think we are all OK when someone else did so. Right? The ploblem here is no one wants to seek for the problem here. It is not just a matter of numbering things. If you are really willing to push this forward, you need to seek out what are actually preventing the move before fixing them. No one is active about this right now.

Updated by duerst (Martin Dürst) about 10 years ago

Shyouhei Urabe wrote:

The situation is that no one in ruby-core is actively willing to do any dirty work to get things move to git. I think we are all OK when someone else did so.

Hello Shyouhei,

I think Sytse is offering to help with the dirty work, which is great. But in my view, the main issue is that when people discussed moving to git, they implied moving to github, which is different from gitlab. But I may be wrong.

Updated by normalperson (Eric Wong) about 10 years ago

The outcome of "move the ruby project to git" probably means
different things to the Ruby community at large,
you (as GitLab CEO), or I...

But first, with Matz's concerns:

  1. Incremental numbering

"git describe" does output a generation number relative to the last tag.
However, I think changing the way we write commit messages to use
descriptive, and (mostly) unique commit titles is better for humans.

  1. Running scripts

Hooks are a part of base git, I don't think there's anything reliant on
GitLab we'd need...

But there are other issues affecting the Ruby project:

  • Some developers do not like or want to use git. So Ruby should
    continue to accept patches against recent tarballs from non-git
    users. Even today, some Linux kernel hackers who do not use git,
    yet contribute much by mailing patches.

  • Merge conflicts with ChangeLog. gnulib has a git-merge-changelog tool
    to help resolve conflicts; but GNU-style ChangeLog seems unhelpful
    given the performance of "git log". I suggest dropping the GNU-style
    ChangeLog entirely (but keep NEWS for non-hackers).

I have some questions about GitLab:

  • Currently, I am not a huge fan of using Redmine, but I tolerate it
    for Ruby development because of:

    1) bidirectional messaging to ruby-core ML
    2) mostly usable with w3m in a non-graphical environment
    

    Can we keep the above things with GitLab?

  • Finally, it would also be great if we allowed unregistered users to
    post on ruby-core and report bugs. In fact, I've been thinking of
    how to move towards accepting unregistered contributors for 2015.

    Can GitLab accept unregistered contributions?

    It would be great if it did. My eventual hope is for Ruby to
    officially accept contributions without any sort of registration
    or login. But I don't know how to make it happen, yet...

Some background: I am relatively new to ruby-core, but I love git and
have been using and contributing to git since 2005. One thing which
impressed me about the git project was how easy it was to send patches:
no registration or obligations of any sort, just email.

I might be able to say I helped git become adopted via git-svn,
but the current state of git adoption is a Pyrrhic victory for
distributed version control:

 Distributed repositories flourish, yet communication (bug reports,
 patch submission, code review, etc) is more centralized than ever.

This is not the future I envisioned when I started contributing to
distributed VCS in 2004 (with GNU arch, before git). The world is
even more centralized now in 2014 than it was in 2004.

I am not sure if GitLab helps with making things less centralized...

Fwiw, I prefer the email-based workflow used by git and Linux
developers. Users have more client and personal workflow choice with
email clients; but the plain-text message exchange remains 100%
interopable between users of different setups.

SMTP is also more robust and fault-tolerant than HTTP for exchanging
messages. Hardly anybody notices when vger.kernel.org (the mailing
list server) goes down because:

  1. git and Linux hackers mainly email affected/responsible parties
    directly and only Cc: the respective mailing list(s) for archival
    purposes. The etiquette is reply-to-all, not reply-to-list like
    most Ruby-related lists.

  2. SMTP servers are designed to handle temporary network outages by
    queueing and retrying. The HTTP client-server model is not.

Of course, HTTP services are immune to spam /* sarcasm ;) */

Everything said, I am available to help ruby with git stuff: hosting,
migrations, workflow, etc... I wrote most of git-svn, and have hosted
git repos since 2005. But the way I prefer to use git is alien to
the Ruby world.

Disclaimer: I do not speak for other git or Ruby developers.
However, if anybody hates git, they are welcome to blame me :)

--
alienperson

Updated by shyouhei (Shyouhei Urabe) about 10 years ago

Martin Dürst wrote:

Shyouhei Urabe wrote:

The situation is that no one in ruby-core is actively willing to do any dirty work to get things move to git. I think we are all OK when someone else did so.

Hello Shyouhei,

I think Sytse is offering to help with the dirty work, which is great.

Yes. His offer is great. I didn't intend to reject that; I just wanted to say it is much difficult than it seems. It took Eric Raymond's full year of preparation plus his full 8 weeks work to migrate Emacs to git. You have to brace the impact of similar magnitude.

But in my view, the main issue is that when people discussed moving to git, they implied moving to github, which is different from gitlab. But I may be wrong.

Git itself is a decentralized thing so GitLab vs GitHub does't matter. The problem is how we collaborate each other; like should we continue using this redmine or move to GitHub issues? Eric Wong's comment https://bugs.ruby-lang.org/issues/10547#note-3 goes deeper in this area.

Updated by naruse (Yui NARUSE) about 10 years ago

  • Status changed from Open to Feedback

Your question sounds "Why CRuby doesn't migrate to git?".
The answer will be "Because there's no person who answer a question "Why CRuby should migrate to git?".

Of course some people answer like "git is now majority" or "GitHub is so great" or "distributed development is the current style".
But there's no planner who summarize pros and cons, and list up issues (and resolve them).

The planner must do

  • Show the merit of git transition (why we should migrate to git and pay cost)
  • List up issues

We already have some long discussion and show some issues in ruby-core:21039 ruby-core:28355 ruby-core:25356.
But after that no one summarize them and maintain the issue list.

The true problem is this.

Actions #7

Updated by hsbt (Hiroshi SHIBATA) about 9 years ago

  • Related to Feature #11741: Migrate Ruby to Git from Subversion added
Actions #8

Updated by Eregon (Benoit Daloze) almost 7 years ago

  • Related to Feature #14551: What's missing to switch to Git instead of using Subversion? added

Updated by hsbt (Hiroshi SHIBATA) almost 7 years ago

  • Assignee set to hsbt (Hiroshi SHIBATA)
Actions #10

Updated by hsbt (Hiroshi SHIBATA) over 6 years ago

  • Related to Misc #14632: [ANN] git.ruby-lang.org added

Updated by hsbt (Hiroshi SHIBATA) almost 6 years ago

  • Status changed from Feedback to Rejected
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0