[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
[email protected] wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85616] Re: Why require autoconf 2.67+
— Vít Ondruch <v.ondruch@...>
2018/02/18
VGhpcyBjb3VsZCBoZWxwIHlvdSB0byBidWlsZCBSdWJ5IHdpdGggb2xkZXIgYXV0b2NvbmYgKDIu
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
[email protected] wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85866] Re: [Ruby trunk Feature#14551] What's missing to switch to Git instead of using Subversion?
From:
Eric Wong <normalperson@...>
Date:
2018-02-28 18:14:12 UTC
List:
ruby-core #85866
[email protected] wrote: > Two points that would be worse for git, the first is general, > the second is personal: > 1) Revisions become meaningless hashes; it's totally > impossible to look at a revision id and know where it fits in > relation to other revision ids. "git describe" can help give you a rough age iff we tag off trunk (or merge the release branches back to trunk); but it currently doesn't work for our repository. But being a decentralized system, git history is non-linear and reliance on serial numbers can be misleading. Decentralization is an alien concept to a lot of people, so they rely on centralized messaging systems (e.g. GitHub, Redmine instances) to make sense of it :< In contrast, git and Linux kernel development messaging is peer-to-peer: developers all email each other directly. The mailing lists are merely an agreed-upon logging/broadcast channel. > 2) Forking, making a change, and sending it back as a pull > request is easy. But staying in sync over the long term is > not. As an example, https://github.com/duerst/ruby says "This > branch is 8734 commits behind ruby:trunk". I have asked people > from github (incl. Aaron Paterson) to add a "sync me up" > button besides this message, but that hasn't happened yet, > even if to me this seems to be a non-brainer. And if I try to > fork again, it tells me that I already have a fork. You can use "git rebase" (or "git merge"(*)) locally for that and push to a new branch. Doing it via a web interface falls down once you hit conflicts and need to fix+test locally. There's no need to rely on proprietary tools at all. (*) I do caution against criss-cross merging because it makes history confusing to follow; rebase is often nicer because it allows you to clean up the history for presentation. Generally, merges should be done by the designated upstream and resolved there, not by downstream. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>