May be because they (LKM) are more open to such architectural and
organization refactorings?
Some maintainers, like Greg Kroah-Hartman and possibly others accept
clean up patches, such thing seems to be unacceptable here on git.
Looks like there is space here only for features and bug fixes.
Nothi
On Tue, Jun 11, 2013 at 4:18 AM, Andres Freund wrote:
> On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:
>> >> You don't agree that 1) a collegial work environment is overrated, 2)
>> >> that the Linux kernel doesn't put an emphasis on being collegial, or
>> >> 3) that it's the most successfu
On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:
> >> You don't agree that 1) a collegial work environment is overrated, 2)
> >> that the Linux kernel doesn't put an emphasis on being collegial, or
> >> 3) that it's the most successful software project in history?
> >
> > Point 1.
>
> Good, s
On Mon, Jun 10, 2013 at 12:34 PM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> It is not bad behavior. It is bad behavior *in your opinion*,
>
> And in essentially everyone else on this list, it seems.
So? An opinion shared by a billion people is still an opinion, not a
fact. To think oth
On Mon, Jun 10, 2013 at 1:11 PM, Martin von Zweigbergk
wrote:
> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
> wrote:
>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
>> wrote:
>>
You need two sides to have an argument.
>>
>>> I disagree. Unless you mean than, whenever a part beh
Yes, sorry. I find this whole story quite amusing (albeit distracting
and unnecessary), but sorry for adding to the spam. I'll be quiet now.
On Mon, Jun 10, 2013 at 11:33 AM, Martin Langhoff
wrote:
> On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
> wrote:
>> On Mon, Jun 10, 2013 at 9:58
On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
wrote:
> On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
> wrote:
>> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
>> wrote:
>>
You need two sides to have an argument.
>>
>>> I disagree. Unless you mean than, whenever a part beh
On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
wrote:
> On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
> wrote:
>
>>> You need two sides to have an argument.
>
>> I disagree. Unless you mean than, whenever a part behaves in a
>> hostile and aggressive way, the other part should just silen
Matthieu Moy wrote:
> https://lkml.org/lkml/2012/4/12/434
> https://lkml.org/lkml/2012/4/15/112
We don't want things taken out of context now, do we? Follow up this
thread [1], if you're interested in that discussion. I did clip out
the quotes you chose on purpose, in the interest of presenting
Felipe Contreras writes:
> It is not bad behavior. It is bad behavior *in your opinion*,
And in essentially everyone else on this list, it seems.
> an opinion that wouldn't be shared by other projects, like the Linux
> kernel.
Googling your name and LKML gives me this in the first page (addres
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
wrote:
>> You need two sides to have an argument.
> I disagree. Unless you mean than, whenever a part behaves in a
> hostile and aggressive way, the other part should just silently
> knuckle under.
You are wrong. If a bum in the street starts
On Mon, Jun 10, 2013 at 11:53 AM, Felipe Contreras
wrote:
> On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano wrote:
>> E.g.
>> convincing people that it is not worth their time interacting with
>> you, especially when there are better things to do like tending to
>> other topics, and you lose the
On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:
>>
>>> One example of killing the entire thread is when I see "This patch
>>> will not be applied" by Felipe in a thread started with his patch.
>>> I unde
On 06/10/2013 07:15 AM, Felipe Contreras wrote:
> On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini
> wrote:
>
>> I do accuse Felipe's *attitude* to bring on and nourish such
>> unpleasantness toxicity. His technical merits and the possible
>> qualities of his patches do *nothing* to remov
Felipe Contreras writes:
> On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:
>
>> One example of killing the entire thread is when I see "This patch
>> will not be applied" by Felipe in a thread started with his patch.
>> I understand that it is his way to say "this patch is retracted"
>> wi
On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini
wrote:
> I do accuse Felipe's *attitude* to bring on and nourish such
> unpleasantness toxicity. His technical merits and the possible
> qualities of his patches do *nothing* to remove or quell such
> issues.
How convenient to accuse me
On Sun, Jun 9, 2013 at 4:42 PM, Michael Haggerty wrote:
> Felipe, I wish that you would devote a small fraction of your prodigious
> energy to the very difficult challenge of feeling empathy,
I do feel empathy, the problem is that you make the assumption that
other people are like you, and that
On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano wrote:
> One example of killing the entire thread is when I see "This patch
> will not be applied" by Felipe in a thread started with his patch.
> I understand that it is his way to say "this patch is retracted"
> without having to explicitly say tha
[Sorry for the full quote, but sometimes, repetita iuvant]
On 06/09/2013 11:42 PM, Michael Haggerty wrote:
> On 06/09/2013 09:11 PM, Johan Herland wrote:
>> [...]
>> FWIW, I'd like to express my support for the opinions expressed by
>> Jonathan, Jeff and Thomas. They accurately describe my impress
On 06/09/2013 09:11 PM, Johan Herland wrote:
> [...]
> FWIW, I'd like to express my support for the opinions expressed by
> Jonathan, Jeff and Thomas. They accurately describe my impression of
> these discussion threads.
I also agree. In my opinion, Felipe, your abrasiveness, your disregard
of pr
Jeff King writes:
> ... We do not have an explicit code of
> conduct on the list, but it is not as if behavior is without
> consequences. If you are not easy to work with, people will get tired of
> dealing with you eventually[1].
FWIW, I have already reached that point and learned to kill certa
Jonathan Nieder wrote:
> Of course the git development community is not organized enough for an
> intervention, but as context I thought I'd mention that that's what
> works.
Atleast this is more interesting that the canned
Felipe-demeanour-complaint people constantly bring up boring everyone
to d
On Sun, Jun 9, 2013 at 2:57 PM, Jonathan Nieder wrote:
> Jeff King wrote:
> Of course that's not the intent: the intent of ignoring someone is to
> hope they'll go away. :)
>
> In the context of other unhealthy behaviors (like alcoholism) there is
> a concept of enabling behavior.
The only one t
On Sun, Jun 9, 2013 at 2:54 PM, Ramkumar Ramachandra wrote:
>> http://article.gmane.org/gmane.comp.version-control.git/225969
This is a good example of an evolving discussion. René Scharfe has
accepted that the API indeed needs work. How exactly it's going to be
fixed is not entirely clear, bu
Jeff King wrote:
> My advice would be to ignore him when the discussion proceeds in an
> unproductive direction.
There is something appealing about that option. The problem is that
it doesn't work, at least for someone that relies on the list as a way
of understanding patches that have been appl
Thomas Rast wrote:
> The arguments arise to a large degree from attempting to review his
> work. Not doing so is not an option, see e.g.:
I don't recall saying that you shouldn't review his work (?). What I
_am_ saying is that there is absolutely no point belaboring over
what's wrong with Felipe
On Sun, Jun 9, 2013 at 2:11 PM, Johan Herland wrote:
> On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras
> wrote:
>> On Sun, Jun 9, 2013 at 1:10 PM, Jeff King wrote:
>>> Go back to my 261 commits, show me one that is "unmindful of technical
>>> details".
>>
>> And you say this thread is an excel
Ramkumar Ramachandra writes:
> Jeff King wrote:
>> I actually think word choice and politeness is only a small part of it,
>> and one that I live without. It is not just _how_ something is said,
>> but _what_ is said. And sometimes what is said does not lead in a
>> productive direction. I found
On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras
wrote:
> On Sun, Jun 9, 2013 at 1:10 PM, Jeff King wrote:
>> Go back to my 261 commits, show me one that is "unmindful of technical
>> details".
>
> And you say this thread is an excellent example of your point that I'm
> unmindful of technical de
On Sun, Jun 9, 2013 at 1:49 PM, Jeff King wrote:
> On Mon, Jun 10, 2013 at 12:14:36AM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > Sorry, I don't have patches. It is a hard problem for which I do not
>> > have the solution, which is kind of my point.
>>
>> So, what is the problem?
On Mon, Jun 10, 2013 at 12:14:36AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Sorry, I don't have patches. It is a hard problem for which I do not
> > have the solution, which is kind of my point.
>
> So, what is the problem? We are moving towards what we think is the
> way forwar
On Sun, Jun 9, 2013 at 1:32 PM, Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> I actually think word choice and politeness is only a small part of it,
>> and one that I live without. It is not just _how_ something is said,
>> but _what_ is said. And sometimes what is said does not lead in a
>>
On Mon, Jun 10, 2013 at 12:02:11AM +0530, Ramkumar Ramachandra wrote:
> This is all very good, Jeff. Various people have expressed what's
> wrong with fc's "demeanour", "tone", and "style of discussion" in
> various different ways at various different points in time. This goes
> on and on and on
Jeff King wrote:
> Sorry, I don't have patches. It is a hard problem for which I do not
> have the solution, which is kind of my point.
So, what is the problem? We are moving towards what we think is the
way forward. Nobody said that it is the theoretical best, but it's
_much_ better than doing
Jeff King wrote:
> I actually think word choice and politeness is only a small part of it,
> and one that I live without. It is not just _how_ something is said,
> but _what_ is said. And sometimes what is said does not lead in a
> productive direction. I found Thomas's comment here:
>
> http://
On Sun, Jun 9, 2013 at 1:22 PM, Jeff King wrote:
> On Sun, Jun 09, 2013 at 11:36:42PM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > I already mentioned elsewhere that I think it would be fine to massage
>> > libgit.a in that direction. I even joined the conversation pointing out
>>
On Sun, Jun 09, 2013 at 11:36:42PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > I already mentioned elsewhere that I think it would be fine to massage
> > libgit.a in that direction. I even joined the conversation pointing out
> > some cases where Felipe's ruby module would break. But
On Sun, Jun 9, 2013 at 1:10 PM, Jeff King wrote:
> On Sun, Jun 09, 2013 at 01:01:30PM -0500, Felipe Contreras wrote:
>> > I do not have an interest in cataloguing past conflicts I and others
>> > have had with you; the list archive has done so.
>>
>> No. There is no such catalog. You made a claim
On Sun, Jun 9, 2013 at 1:06 PM, Ramkumar Ramachandra wrote:
> Jeff King wrote:
>> I already mentioned elsewhere that I think it would be fine to massage
>> libgit.a in that direction. I even joined the conversation pointing out
>> some cases where Felipe's ruby module would break. But I do not thi
On Sun, Jun 09, 2013 at 01:01:30PM -0500, Felipe Contreras wrote:
> >> > Sorry, but I don't agree, and I want to publicly state my opinion so
> >> > that Jonathan (and other bystanders on the list) knows that he is not
> >> > alone in his opinions.
> >>
> >> You don't agree that 1) a collegial wor
Jeff King wrote:
> I already mentioned elsewhere that I think it would be fine to massage
> libgit.a in that direction. I even joined the conversation pointing out
> some cases where Felipe's ruby module would break. But I do not think
> that moving code in and out of libgit.a is an important first
On Sun, Jun 9, 2013 at 12:55 PM, Jeff King wrote:
> On Sun, Jun 09, 2013 at 03:28:48PM +0530, Ramkumar Ramachandra wrote:
>
>> Jeff King wrote:
>> > Sorry that I cannot show you the source code, but you may interested to
>> > know that libgit2 powers:
>>
>> Yes, I'm well aware of these: libgit2 is
On Sun, Jun 09, 2013 at 06:18:51PM +0530, Ramkumar Ramachandra wrote:
> > I have consistently found your demeanor on the list to be very
> > unfriendly and difficult to work with. It is one thing to have honest
> > and straight talk, and another thing to be obstinate, unmindful of
> > feedback (bo
On Sun, Jun 9, 2013 at 12:53 PM, Thomas Rast wrote:
> You have a tendency, when facing arguments by someone who does not agree
> with you, of picking out one (usually minor) point of their statement
> and attacking just *that* on grounds that are usually much harder to
> argue, without regard for
On Sun, Jun 9, 2013 at 12:40 PM, Jeff King wrote:
> On Sun, Jun 09, 2013 at 07:15:45AM -0500, Felipe Contreras wrote:
>
>> > Sorry, but I don't agree, and I want to publicly state my opinion so
>> > that Jonathan (and other bystanders on the list) knows that he is not
>> > alone in his opinions.
>
On Sun, Jun 09, 2013 at 03:28:48PM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Sorry that I cannot show you the source code, but you may interested to
> > know that libgit2 powers:
>
> Yes, I'm well aware of these: libgit2 is LGPL, because of which these
> three proprietary applicat
Felipe Contreras writes:
> On Sun, Jun 9, 2013 at 12:26 AM, Jeff King wrote:
>> On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:
>>
>>> > Definitely, yes. Even if you look at the impact on code alone and
>>> > don't care about the people, destroying a collegial work environment
On Sun, Jun 09, 2013 at 07:15:45AM -0500, Felipe Contreras wrote:
> > Sorry, but I don't agree, and I want to publicly state my opinion so
> > that Jonathan (and other bystanders on the list) knows that he is not
> > alone in his opinions.
>
> You don't agree that 1) a collegial work environment
On Sun, Jun 9, 2013 at 7:48 AM, Ramkumar Ramachandra wrote:
> Jeff King wrote:
>>> > Definitely, yes. Even if you look at the impact on code alone and
>>> > don't care about the people, destroying a collegial work environment
>>> > is harmful enough to the code to outweigh the (admittedly often
>
Jeff King wrote:
>> > Definitely, yes. Even if you look at the impact on code alone and
>> > don't care about the people, destroying a collegial work environment
>> > is harmful enough to the code to outweigh the (admittedly often
>> > useful) patches.
>>
>> A collegial work environment is overrat
On Sun, Jun 9, 2013 at 12:26 AM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:
>
>> > Definitely, yes. Even if you look at the impact on code alone and
>> > don't care about the people, destroying a collegial work environment
>> > is harmful enough to the co
On Sat, Jun 8, 2013 at 11:34 PM, Jeff King wrote:
> On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote:
>
>> Let the code speak. Show me a script in any language that does
>> something useful using libgit2, doing the equivalent to at least a
>> couple of 'git foo' commands.
>
> Sorry
Jeff King wrote:
> Sorry that I cannot show you the source code, but you may interested to
> know that libgit2 powers:
Yes, I'm well aware of these: libgit2 is LGPL, because of which these
three proprietary applications have been made possible. Isn't it
completely orthogonal to the discussion abo
On Sat, Jun 08, 2013 at 09:17:56PM -0500, Felipe Contreras wrote:
> > Definitely, yes. Even if you look at the impact on code alone and
> > don't care about the people, destroying a collegial work environment
> > is harmful enough to the code to outweigh the (admittedly often
> > useful) patches.
On Sat, Jun 08, 2013 at 09:20:54AM -0500, Felipe Contreras wrote:
> Let the code speak. Show me a script in any language that does
> something useful using libgit2, doing the equivalent to at least a
> couple of 'git foo' commands.
Sorry that I cannot show you the source code, but you may interes
On Sat, Jun 8, 2013 at 10:21 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> A collegial work environment is overrated, and proof of that the Linux
>> kernel, where honest and straight talk is the bread and butter of the
>> mailing list.
>
> An aside, since it doesn't bear too much on th
Felipe Contreras wrote:
> A collegial work environment is overrated, and proof of that the Linux
> kernel, where honest and straight talk is the bread and butter of the
> mailing list.
An aside, since it doesn't bear too much on the topic at hand:
For what it's worth, in my experience the people
On Sat, Jun 8, 2013 at 8:40 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> Just the past three months I've probably done more work than anybody
>> else[1], and you would ban me because you don't like my words?
>
> Definitely, yes. Even if you look at the impact on code alone and
> don'
Felipe Contreras wrote:
> Just the past three months I've probably done more work than anybody
> else[1], and you would ban me because you don't like my words?
Definitely, yes. Even if you look at the impact on code alone and
don't care about the people, destroying a collegial work environment
i
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote:
> If I were managing this list, I would ban mails from you, since this
> discussion style does more harm than good.
There is a nice motto around: "Talk is cheap. Show me the code."
Just the past three months I've probably done more work th
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder wrote:
> Felipe Contreras wrote:
>
>> This has nothing to do with better strategy, it has everything to do
>> with gut feelings and tradition. Not reasons.
>
> I try to help you, and you insult me. I don't think this is worth it.
I didn't direct t
Felipe Contreras wrote:
> This has nothing to do with better strategy, it has everything to do
> with gut feelings and tradition. Not reasons.
I try to help you, and you insult me. I don't think this is worth it.
If I were managing this list, I would ban mails from you, since this
discussion st
On Sat, Jun 8, 2013 at 11:49 AM, Jonathan Nieder wrote:
> Duy Nguyen wrote:
>
>> libgit.a is just a way of grouping a bunch of objects together, not a
>> real library and not meant to be. If you aim something more organized,
>> please show at least a roadmap what to move where.
>
> Exactly. There
Duy Nguyen wrote:
> libgit.a is just a way of grouping a bunch of objects together, not a
> real library and not meant to be. If you aim something more organized,
> please show at least a roadmap what to move where.
Exactly. There are some rough plans I would like to help with in the
direction o
On Sat, Jun 8, 2013 at 9:10 AM, Duy Nguyen wrote:
> Do we want to
> freeze libgit.a API so that scripts will not be audited and changed
> unncessarily?
No. Until we ship libgit.so the API remains internal, and free to change.
> I still think that binding new languages to a clean library
> like
On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra wrote:
> I'm not saying that we can convert libgit.a into something that's
> usable as a long-running process by production servers tomorrow. All
> I'm saying is that it might be possible to get ruby (and possibly
> other languages) to call int
On Sat, Jun 8, 2013 at 8:34 AM, Ramkumar Ramachandra wrote:
> Duy Nguyen wrote:
>> I _think_ the reason is because git was never written as a reusable
>> library in mind from the beginning.
>
> We cannot reverse-engineer intents, but I tend to agree with this. My
> question is: so what? Is it im
Duy Nguyen wrote:
> I _think_ the reason is because git was never written as a reusable
> library in mind from the beginning.
We cannot reverse-engineer intents, but I tend to agree with this. My
question is: so what? Is it impossible to do now?
> So global states and die() exist.
> Worse, "run
On Sat, Jun 8, 2013 at 8:15 AM, Duy Nguyen wrote:
> So instead of redoing it again, I think it's better that you help
> libgit2 guys improve it to the extend that git commands can be easily
> reimplemented. Then bring up the discussion about using libgit2 in C
> Git again.
There's no reason not
On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
> wrote:
>> On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:
>>> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
>>> wrote:
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
> On Sat
On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra wrote:
> Duy Nguyen wrote:
>>> until libgit.a == libgit2. Done.
>>
>> Read up about the introduction of libgit2, why it was created in the
>> first place instead of moving a few files around renaming libgit.a to
>> libgit2.a. Unless you have a d
Duy Nguyen wrote:
>> until libgit.a == libgit2. Done.
>
> Read up about the introduction of libgit2, why it was created in the
> first place instead of moving a few files around renaming libgit.a to
> libgit2.a. Unless you have a different definition of "==" than I do.
As far as I know, there was
On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras
wrote:
> On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
>> wrote:
>>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
wrote:
On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
> wrote:
>> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
>>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
>>> wrote:
This code is only useful for cherry-pick and revert built-ins,
On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras
wrote:
> On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
>> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
>> wrote:
>>> This code is only useful for cherry-pick and revert built-ins, nothing
>>> else, so let's make it a builtin object, but ma
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen wrote:
> On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
> wrote:
>> This code is only useful for cherry-pick and revert built-ins, nothing
>> else, so let's make it a builtin object, but make sure 'git-sequencer'
>> is not generated.
>
> As you can see
On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras
wrote:
> This code is only useful for cherry-pick and revert built-ins, nothing
> else, so let's make it a builtin object, but make sure 'git-sequencer'
> is not generated.
As you can see, the convention is builtin/foo.c corresponds to git-foo
(and
This code is only useful for cherry-pick and revert built-ins, nothing
else, so let's make it a builtin object, but make sure 'git-sequencer'
is not generated.
Signed-off-by: Felipe Contreras
---
Makefile | 9 ++---
sequencer.c => builtin/sequencer.c | 0
sequencer.
78 matches
Mail list logo
