On Sun, Jun 9, 2013 at 6:29 PM, Junio C Hamano wrote:
> When otherwise silent old-timers feel a need to come during a
> discussion that might affect the course of the project in a major
> way, we should pay more attention, not less, to what they say (I am
> not saying "we should blindly follow").
Ramkumar Ramachandra writes:
> Do you think that the opinions of
> inactive community members and non-contributors are _more_ valuable
> than those of active contributors, or am I missing something?
I am not Dscho, but it probably is worth saying this anyway.
6d297f81373e (Status update on merg
Johannes Schindelin wrote:
>> Correct. The opinions of inactive community members and
>> non-contributors are less useful.
>
> I humbly suggest to treat other people's contribution with the same
> respect you want yours' to be treated.
What?! When did I disrespect other people's contributions?
Hi Duy,
On Sat, 8 Jun 2013, Duy Nguyen wrote:
> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
> wrote:
> > Hi Greg,
> >
> > On Thu, 6 Jun 2013, Greg Troxel wrote:
> >
> >> As one of the people who helps maintain git packages in pkgsrc, my
> >> initial reaction is negative to adding a ruby
Hi Ram,
On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> > While at it, why not re-evaluate the whole msysgit approach? I bet we
> > don't need a whole separate project just to create a Windows
> > installer. I've written Windows installers before, it's very easy to
> >
Hi Ram,
On Sat, 8 Jun 2013, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
> >> Also we heard from no regular/high-value reviewers that they feel
> >> comfortable reviewing additions in Ruby.
> >
> > Correction; *current* regular/high-value reviewers.
>
> Correct. The opinions of inactiv
On Sat, Jun 8, 2013 at 9:23 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote:
>
>> > No, I didn't say that at all.
>>
>> Then you truly think libgit2 will ever reach the point where it can
>> replace libgit.a?
>
> I don't know. It may. Or something like it ma
On Sat, Jun 08, 2013 at 08:17:08PM -0500, Felipe Contreras wrote:
> > No, I didn't say that at all.
>
> Then you truly think libgit2 will ever reach the point where it can
> replace libgit.a?
I don't know. It may. Or something like it may. It is certainly not
ready to do so yet, but perhaps one
On Sat, Jun 8, 2013 at 7:10 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote:
>
>> > These are problems that can be solved. But there is a lot of work
>> > involved in finding these subtle bugs and coming up with fixes. I think
>> > you would be better off wo
On Sat, Jun 08, 2013 at 12:40:19PM -0500, Felipe Contreras wrote:
> > These are problems that can be solved. But there is a lot of work
> > involved in finding these subtle bugs and coming up with fixes. I think
> > you would be better off working on an implementation of git that was
> > designed
On Sat, Jun 8, 2013 at 12:15 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote:
>
>> > There are a lot of static variables in builtin/ (and outside too),
>> > which make it non-entrant, or at least not safe.
>>
>> So?
>>
>> > fork provides a process space isol
On Sat, Jun 08, 2013 at 08:20:28AM -0500, Felipe Contreras wrote:
> > There are a lot of static variables in builtin/ (and outside too),
> > which make it non-entrant, or at least not safe.
>
> So?
>
> > fork provides a process space isolation, some depend on that.
>
> Process space isolation f
On Sat, Jun 8, 2013 at 7:07 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
> wrote:
>> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:
>>> but how many people on this
>>> list understand git design and limits _and_ ruby's good enough to spot
>>> the bugs?
>>
>> Now y
On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
wrote:
> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
>> wrote:
>>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
wrote:
On Sat, Jun 8, 2013 at 6:20 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras
> wrote:
>> On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:
>>> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
>>> wrote:
> The reviewer pool for code written in a new language _must_ be
On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
> wrote:
>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
>>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>>> wrote:
Hi Greg,
On Thu, 6 Jun 2013, Greg Troxel wrote:
>
On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
wrote:
> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>> wrote:
>>> Hi Greg,
>>>
>>> On Thu, 6 Jun 2013, Greg Troxel wrote:
>>>
As one of the people who helps maintain git packages
On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras
wrote:
> On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
>> wrote:
The reviewer pool for code written in a new language _must_ be
seeded by some from the current set of reviewers whos
On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
> wrote:
>>> The reviewer pool for code written in a new language _must_ be
>>> seeded by some from the current set of reviewers whose judgement
>>> I/we can trust.
>>
>> By that standard nothing
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen wrote:
> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
> wrote:
>> Hi Greg,
>>
>> On Thu, 6 Jun 2013, Greg Troxel wrote:
>>
>>> As one of the people who helps maintain git packages in pkgsrc, my
>>> initial reaction is negative to adding a ruby de
On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
wrote:
>> The reviewer pool for code written in a new language _must_ be
>> seeded by some from the current set of reviewers whose judgement
>> I/we can trust.
>
> By that standard nothing will ever change. Ever.
>
> Even twenty years from now, you
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
wrote:
> Hi Greg,
>
> On Thu, 6 Jun 2013, Greg Troxel wrote:
>
>> As one of the people who helps maintain git packages in pkgsrc, my
>> initial reaction is negative to adding a ruby dependency.
>
> My initial reaction, too. It was hard enough to
On Fri, Jun 7, 2013 at 2:55 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> I think we heard enough from packaging folks that a new dependency
>>> is unwelcome.
>>
>> What are you talking about? Which are these "packaging folks" we heard from?
>
> Dscho is one of the primary people beh
Felipe Contreras writes:
>> I think we heard enough from packaging folks that a new dependency
>> is unwelcome.
>
> What are you talking about? Which are these "packaging folks" we heard from?
Dscho is one of the primary people behind msysgit effort, and I
consulted with others from the circle w
Ramkumar Ramachandra wrote:
> commit a lot of good ruby code to contrib*
Oh, by the way: I have a project idea. There's this really popular
project called hub[1] that has an implementation of the GitHub API in
ruby. Unfortunately, it's a terrible piece of software because it
creates an extra lay
Felipe Contreras wrote:
> While at it, why not re-evaluate the whole msysgit approach? I bet we
> don't need a whole separate project just to create a Windows
> installer. I've written Windows installers before, it's very easy to
> do from Linux.
Yeah, taking the pain out of msysgit packaging woul
On Thu, Jun 6, 2013 at 4:31 PM, Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> Git is probably the _last_ thing
>> to be complaining about when it comes to packaging.
>
> It would be nice if contrib/ files supported the usual "make; make
> install; m
Felipe Contreras wrote:
>> Also we heard from no regular/high-value reviewers
>> that they feel comfortable reviewing additions in Ruby.
>
> Correction; *current* regular/high-value reviewers.
Correct. The opinions of inactive community members and
non-contributors are less useful.
> We could ch
On Thu, Jun 6, 2013 at 3:19 PM, David Lang wrote:
> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>
>> David Lang wrote:
>>>
>>> Perl use may or may not be declining (depending on how you measure it),
>>> but
>>> are you really willing to take on the task of re-writing everything
>>> that's
>>>
On Thu, Jun 6, 2013 at 10:25 PM, Johannes Schindelin
wrote:
> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>
>> Johannes Schindelin wrote:
>> > My initial reaction, too. It was hard enough to get Perl included with Git
>> > for Windows (because of that pesky Subversion dependency).
>>
>> Nevert
On Fri, Jun 7, 2013 at 2:00 PM, Matthieu Moy
wrote:
> Ramkumar Ramachandra writes:
>
>>> Whether it's based on POSIX is an implementation detail for the user.
>>> The real question is more command-line Vs GUI than POSIX/Win32. Some
>>> Linux users like GUI, some windows users use command-line. I
On Fri, Jun 7, 2013 at 10:20 AM, Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> I think Felipe is using the argument that perl is declining to answer
>> the question "why didn't you write git-related in perl instead?";
>> that's it.
>
> A question which nobody asked, I presume?
>
> I t
Ramkumar Ramachandra writes:
>> Whether it's based on POSIX is an implementation detail for the user.
>> The real question is more command-line Vs GUI than POSIX/Win32. Some
>> Linux users like GUI, some windows users use command-line. I tried IDE
>> integration with EGIT, and quite frankly I end
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
I think he way forward on Windows is
Why is there only one way forward? Why do you get to pick it, given
that you've said you're not interested in working on it?
[...]
I never understood why
use
Matthieu Moy wrote:
> Visual Studio now has official Git support from MS (based on libgit2 if
> I understood correctly). That's cool, but not a reason to kill msysgit
> IMHO ;-).
Oh, I'm not interested in killing anything. If people want msysgit,
they will work on it: I'm nobody to say otherwise.
Ramkumar Ramachandra writes:
> I think he way forward on Windows is an implementation like libgit2 or
> git# with some sort of gui/ide integration. I never understood why
> users on Windows want to use something as POSIX'y as git.git.
Whether it's based on POSIX is an implementation detail for
Ramkumar Ramachandra wrote:
> I think he way forward on Windows is
Why is there only one way forward? Why do you get to pick it, given
that you've said you're not interested in working on it?
[...]
> I never understood why
> users on Windows want to
Matthieu Moy writes:
> The POSIX guys shouldn't move faster than the Windows guys can follow.
That is a very good summary.
It does not mean everybody must always crawl at the same pace as the
slowest people. But it is one of the important things we should
consider, when we have choices to make
Matthieu Moy wrote:
> I think it should be "the Git for Windows community", and my feeling is
> that the community developing Git for POSIX systems is far more active
> than the one making it work for Windows (although we may now have more
> windows users than unix users).
If I can be excused for
Matthieu Moy wrote:
> Reading Git for Windows's FAQ
> ( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ),
> it seems rather clear that the TODO-list is already long to have a
> correct Perl support (I'm quite admirative of the work done already).
> The POSIX guys shouldn't move
Ramkumar Ramachandra writes:
> Johannes Schindelin wrote:
>> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>>> Johannes Schindelin wrote:
>>> > My initial reaction, too. It was hard enough to get Perl included with Git
>>> > for Windows (because of that pesky Subversion dependency).
>>>
>>> Nev
Matthieu Moy writes:
> * Ask the user to build external programs with
>
> make GIT_ROOT=where/git/lives/
>
> * or, ask users to checkout the external program as a subdirectory of
> git.git to build it (for example, clang's build installation ask you
> to put clang as a subdirectory of LLVM'
Junio C Hamano wrote:
> So at least for now, the conclusion is to take approach #1, i.e.
> somebody who finds "related" a good addition rewrites it in Perl to
> promote it out of contrib/ once the design issues settle (of course
> it is still a possibility that no such volunteer appears).
We'll th
Johannes Schindelin wrote:
> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>> Johannes Schindelin wrote:
>> > My initial reaction, too. It was hard enough to get Perl included with Git
>> > for Windows (because of that pesky Subversion dependency).
>>
>> Nevertheless, we had to do it, and we did
Ramkumar Ramachandra writes:
> I think Felipe is using the argument that perl is declining to answer
> the question "why didn't you write git-related in perl instead?";
> that's it.
A question which nobody asked, I presume?
I think we heard enough from packaging folks that a new dependency
is u
David Lang wrote:
> Well, Felipe is saying that Perl is dieing and we should re-write everything
> that exists in Perl to Ruby.
I don't agree with that opinion. More generally, I think the entire
discussion on what _should_ or _should not_ be done is rubbish. What
_will_ and _will not_ happen de
Hi Ram,
On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
> Johannes Schindelin wrote:
> > My initial reaction, too. It was hard enough to get Perl included with Git
> > for Windows (because of that pesky Subversion dependency).
>
> Nevertheless, we had to do it, and we did it.
That is not quite
Ramkumar Ramachandra wrote:
> Git is probably the _last_ thing
> to be complaining about when it comes to packaging.
It would be nice if contrib/ files supported the usual "make; make
install; make clean" targets. That's missing functionality that does
matter
On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
David Lang wrote:
Perl use may or may not be declining (depending on how you measure it), but
are you really willing to take on the task of re-writing everything that's
in Perl into another language and force all developers of scripts to learn
tha
Greg Troxel wrote:
> It's not about what I want. It's about making choices that affect other
> people, and trying to find a plan that will be overall reasonable;
> that's the essence of stewardship in packaging. Compiling for just
> myself is far easier.
Have you asked the SBCL or Google-Chrome
On 06/06/2013 01:46 AM, Felipe Contreras wrote:
> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:
>>
>> Good thing you are being objective and leaving out the Python 3.0
>> mess, the long legacy of backwards compatibility in the Perl
>> community, the active community behind it, its extensive port
Johannes Schindelin wrote:
> My initial reaction, too. It was hard enough to get Perl included with Git
> for Windows (because of that pesky Subversion dependency).
Nevertheless, we had to do it, and we did it. We will do it again, if
we get enough important code written in Ruby.
> As you can se
David Lang wrote:
> Perl use may or may not be declining (depending on how you measure it), but
> are you really willing to take on the task of re-writing everything that's
> in Perl into another language and force all developers of scripts to learn
> that other language? what's the ROI of this?
L
On Wed, Jun 5, 2013 at 6:13 AM, Michael Haggerty wrote:
>
> But my main point is that I think it would be easier to phase out
> contrib/ if there were a good alternate way of providing visibility to
> "satellite" projects. The relevant Git wiki page [1] is the most likely
> candidate, but it is a
On Thu, Jun 6, 2013 at 12:16 PM, Greg Troxel wrote:
>
> Felipe Contreras writes:
>
>> On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel wrote:
>>>
>>> git is a core tool that people use on almost the smallest of boxes,
>>> perhaps even replacing rcs for managing local config files. On such
>>> machin
On Thu, Jun 6, 2013 at 11:09 AM, David Lang wrote:
> On Thu, 6 Jun 2013, Felipe Contreras wrote:
>
>> In the end my point remains unchanged; Perl is declining, so it would
>> be wise for the future to use another scripting language instead.
>
>
> Perl use may or may not be declining (depending on
Felipe Contreras writes:
> On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel wrote:
>>
>> git is a core tool that people use on almost the smallest of boxes,
>> perhaps even replacing rcs for managing local config files. On such
>> machines, even perl may be large, but a second scripting language se
On Thu, 6 Jun 2013, Felipe Contreras wrote:
In the end my point remains unchanged; Perl is declining, so it would
be wise for the future to use another scripting language instead.
Perl use may or may not be declining (depending on how you measure it), but are
you really willing to take on the
Hi Greg,
On Thu, 6 Jun 2013, Greg Troxel wrote:
> As one of the people who helps maintain git packages in pkgsrc, my
> initial reaction is negative to adding a ruby dependency.
My initial reaction, too. It was hard enough to get Perl included with Git
for Windows (because of that pesky Subversio
On Thu, Jun 6, 2013 at 9:54 AM, Greg Troxel wrote:
>
> As one of the people who helps maintain git packages in pkgsrc, my
> initial reaction is negative to adding a ruby dependency. There are
> several not-entirely-related reasons:
>
> git is a core tool that people use on almost the smallest of
As one of the people who helps maintain git packages in pkgsrc, my
initial reaction is negative to adding a ruby dependency. There are
several not-entirely-related reasons:
git is a core tool that people use on almost the smallest of boxes,
perhaps even replacing rcs for managing local config fi
On Thu, Jun 6, 2013 at 9:41 AM, Barry Fishman wrote:
> On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote:
>> I don't know what you are saying, but it clearly has nothing to do
>> with the point.
>>
>> Perl is declining, and it would be wise to use another language
>> instead of it.
>
> You want a
On 2013-06-06 10:09:21 EDT, Felipe Contreras wrote:
> I don't know what you are saying, but it clearly has nothing to do
> with the point.
>
> Perl is declining, and it would be wise to use another language
> instead of it.
You want a simple statement. I don't particulary like Perl, but it has
wo
On Thu, Jun 6, 2013 at 8:46 AM, Barry Fishman wrote:
>
> On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:
>> Nobody is judging the usefulness of a language, I have plenty of
>> arguments for that, but this is about popularity.
>
> I used "usefulness" in its general vague sense. It is useful t
On 2013-06-06 09:01:48 EDT, Felipe Contreras wrote:
> On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman wrote:
>>
>> On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
>>> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:
Good thing you are being objective and leaving out the Python 3.0
mes
On Thu, Jun 6, 2013 at 7:24 AM, Barry Fishman wrote:
>
> On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
>> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:
>>> Good thing you are being objective and leaving out the Python 3.0
>>> mess, the long legacy of backwards compatibility in the Perl
>>
Michael Haggerty writes:
> * at the source-code level, a tool in contrib can take advantage of some
> of the Git build/test infrastructure, though I don't know whether they
> currently do.
They do not do much AFAICT. For example, contrib/subtree/t/Makefile is
essentially copy-pasted from Git's e
On 2013-06-06 03:46:59 EDT, Felipe Contreras wrote:
> On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:
>> Good thing you are being objective and leaving out the Python 3.0
>> mess, the long legacy of backwards compatibility in the Perl
>> community, the active community behind it, its extensive po
On Thu, Jun 6, 2013 at 2:26 AM, demerphq wrote:
> On 5 June 2013 16:45, Felipe Contreras wrote:
>> On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano wrote:
>> That might make sense for the shorter term, but in longer term I see
>> Perl as declining in favor of other languages. It's only a matter of
On 5 June 2013 16:45, Felipe Contreras wrote:
> On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano wrote:
> That might make sense for the shorter term, but in longer term I see
> Perl as declining in favor of other languages. It's only a matter of
> time before Ruby surpasses Perl in popularity, and
Michael Haggerty writes:
> For completeness, let me point out two other small advantages of contrib:
>
> * a tool in contrib can assume that it is being bundled with the
> corresponding version of Git, and therefore doesn't necessarily have to
> go to the effort of supporting older versions of Gi
On Tue, Jun 4, 2013 at 7:04 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
> I however do not know how much extra burden it would place to add
> dependencies to platform folks, so obviously the safer approach is 1
> at least in the immediate future. My understanding is that msysgit
> folks
On Tue, Jun 4, 2013 at 10:02 PM, David Lang wrote:
> On Tue, 4 Jun 2013, Junio C Hamano wrote:
>
>> Junio C Hamano writes:
>>
>>
>> On Ruby:
>>
>> Assuming "related" is a good idea, to make it as the proper part of
>> the system out of contrib/ when its design review phase is finished,
>> one of
On 06/05/2013 02:04 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> * fc/contrib-related (2013-06-03) 4 commits
>> - contrib: related: parse committish like format-patch
>> - contrib: related: add option to parse from committish
>> - contrib: related: add support for multiple patches
>
On Tue, 4 Jun 2013, Junio C Hamano wrote:
Junio C Hamano writes:
On Ruby:
Assuming "related" is a good idea, to make it as the proper part of
the system out of contrib/ when its design review phase is finished,
one of these things has to happen:
1. Find a volunteer to rewrite it in one of t
Junio C Hamano writes:
> * fc/contrib-related (2013-06-03) 4 commits
> - contrib: related: parse committish like format-patch
> - contrib: related: add option to parse from committish
> - contrib: related: add support for multiple patches
> - Add new git-related helper to contrib
>
> Waiting
76 matches
Mail list logo
