Re: [PATCH 2/2] Move sequencer to builtin
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. Nothing else. I'm not saying that is bad at all. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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, so we agree that a project doesn't need a collegial work environment to be extremely and amazingly successful. In fact, any rational person would keep an open mind to the fact that perhaps it actually _helps_ to not have such environment, based on the evidence. Just from skimming both lists, most of the time I find lkml to be nicer (and more collegial) to read because it has a better atmosphere than git@ had in the last year or two. And yes, a good atmosphere plays an important role. One of the reasons is that it makes it easier to discern arguments based on personality disputes - which certainly exist on lk - from actual technical disagreements that need to be resolved. Greetings, Andres Freund -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Tue, Jun 11, 2013 at 4:18 AM, Andres Freund and...@anarazel.de 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 successful software project in history? Point 1. Good, so we agree that a project doesn't need a collegial work environment to be extremely and amazingly successful. In fact, any rational person would keep an open mind to the fact that perhaps it actually _helps_ to not have such environment, based on the evidence. Just from skimming both lists, most of the time I find lkml to be nicer (and more collegial) to read because it has a better atmosphere than git@ had in the last year or two. A better atmosphere, yes, because they know how to avoid flamewars, and concentrate on technical issues, not because they have a collegial work environment. Unless you think this reply[1] is collegial. Even though I haven't been following Linux mailing lists that closely lately, I still manage to see a lot of these kinds of replies. And yes, a good atmosphere plays an important role. One of the reasons is that it makes it easier to discern arguments based on personality disputes - which certainly exist on lk - from actual technical disagreements that need to be resolved. That's right, but that's not because everyone is collegial in LKML, which they most certainly are not. Linus being one of many examples. [1] http://article.gmane.org/gmane.linux.usb.general/85952 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano gits...@pobox.com 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 that he now understands that reviews showed why the patch was wrong or that he thanks the reviewer for enlightening him. You are wrong. There's nothing wrong with the patch. ... I thought you understood that code should speak, but apparently you don't. That is exactly the point Peff raised (and I agreed with), isn't it? Bad behaviour (being difficult to work with) has consequences. 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 chance to show that your patches are good when they indeed are (I don't even know if these patches in question are good, and I am not going to find out). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)
On 06/10/2013 07:15 AM, Felipe Contreras wrote: On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini stefano.lattar...@gmail.com 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 I accuse your *attitude*, which IMHO is now even damaging your code (that is, the acceptance of your code on the part of the community). and not the others who have as much fault if not more. Sorry, this is just your opinion. Mine, by observing the proceeding from the outside, is different: my opinion is that your attitude is the problem. 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. The difference is; I did actually send code. Code that is good, code that works, and code that users need. As I said, as a *user* (since I'm definitely not a Git developer in any sense of the word), I also need a calm and constructive environment in the community. Or are you interested only in users that can benefit from things you are good at? Regards, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano gits...@pobox.com 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 that he now understands that reviews showed why the patch was wrong or that he thanks the reviewer for enlightening him. You are wrong. There's nothing wrong with the patch. ... I thought you understood that code should speak, but apparently you don't. That is exactly the point Peff raised (and I agreed with), isn't it? Bad behaviour (being difficult to work with) has consequences. It is not bad behavior. It is bad behavior *in your opinion*, an opinion that wouldn't be shared by other projects, like the Linux kernel. 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 chance to show that your patches are good when they indeed are (I don't even know if these patches in question are good, and I am not going to find out). You are hurting the Git project by doing that, and our users, specially our Windows users. I thought you were a good maintainer. But apparently you would rather listen to the people that only complain, rather than actual code, that actually improves things. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Mon, Jun 10, 2013 at 11:53 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano gits...@pobox.com 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 chance to show that your patches are good when they indeed are (I don't even know if these patches in question are good, and I am not going to find out). You are hurting the Git project by doing that, and our users, specially our Windows users. I thought you were a good maintainer. But apparently you would rather listen to the people that only complain, rather than actual code, that actually improves things. And this in fact has a name; *bias*. It is bad in any human endeavor, and in logic and argumentation, letting yourself be blinded by who is making the arguments, rather than the arguments themselves has a name; ad hominem. That is a mistake. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini stefano.lattar...@gmail.com 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 talking about you about why you are going to hell, and you reply to him and argue. Who has the fault of starting an argument? Both. Maybe you have even more blame. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
Felipe Contreras felipe.contre...@gmail.com 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 (addressed to you): https://lkml.org/lkml/2012/4/12/434 I'm stupider for just reading your email. Go away. https://lkml.org/lkml/2012/4/15/112 I'll make one more try at explaining to you, but then I'll just set my mail reader to ignore you, because judging by past performance (not just in this thread) you will just continue to argue. I don't follow the lkml so maybe I've just been unlucky and Google didn't show me an accurate sample, but arguing that your behavior is welcome on the LKML seems weird. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 evidence in an unbiased manner. I don't follow the lkml so maybe I've just been unlucky and Google didn't show me an accurate sample, but arguing that your behavior is welcome on the LKML seems weird. Are people criticizing his discussion style, tone, and demeanour, instead of focusing on the argument? [1]: http://thread.gmane.org/gmane.linux.kernel/1280458/focus=8675 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)
On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini stefano.lattar...@gmail.com 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 talking about you about why you are going to hell, and you reply to him and argue. Who has the fault of starting an argument? I'm not sure I follow the analogy. Are you the bum or the passer-by? Sorry, couldn't help it. :-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)
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 martin.langh...@gmail.com wrote: On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk martinv...@gmail.com wrote: On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini stefano.lattar...@gmail.com 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 talking about you about why you are going to hell, and you reply to him and argue. Who has the fault of starting an argument? I'm not sure I follow the analogy. Are you the bum or the passer-by? http://xkcd.com/386/ Someone is wrong on the Internet! Let it be. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad attitudes and problems in the Git community (was: Re: [PATCH 2/2] Move sequencer to builtin)
On Mon, Jun 10, 2013 at 1:11 PM, Martin von Zweigbergk martinv...@gmail.com wrote: On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini stefano.lattar...@gmail.com 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 talking about you about why you are going to hell, and you reply to him and argue. Who has the fault of starting an argument? I'm not sure I follow the analogy. Are you the bum or the passer-by? It doesn't matter. Both sides are at fault of an argument. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Mon, Jun 10, 2013 at 12:34 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Felipe Contreras felipe.contre...@gmail.com 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 otherwise is to fall in the argumentum ad populum fallacy. 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 (addressed to you): https://lkml.org/lkml/2012/4/12/434 I'm stupider for just reading your email. Go away. https://lkml.org/lkml/2012/4/15/112 I'll make one more try at explaining to you, but then I'll just set my mail reader to ignore you, because judging by past performance (not just in this thread) you will just continue to argue. I don't follow the lkml so maybe I've just been unlucky and Google didn't show me an accurate sample, but arguing that your behavior is welcome on the LKML seems weird. Now you are committing two fallacies at the same time; argument from authority and hasty generalization. Yes, Linus Torvalds lost his temper with me, he has done so with so many people that's hardly surprising. I still think he is wrong, but to prove it I need information that is not readily available, and it's not that important anyway. That doesn't mean that Linus' opinion is shared by the list (or any other Linux mailing list); if you think so you are committing the hasty generalization fallacy. And if you think Linus' opinion means something is a fact you commit the argument from authority fallacy. None of this mean that my patches are not welcome in LKML, or any other Linux mailing list. I repeat what Linus said: Talk is cheap, show me the code. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 about how best to lib'ify git.git though? From what I understand, fc is not interested in building another application leveraging libgit.a or libgit2; he's interested in improving libgit.a and getting more users. It is definitely not feature-complete when compared with git.git. But I do think it is in a state that is usable for quite a few tasks. What is this task you are discussing? fc is talking about improving libgit.a and getting an official git library with many users. Answer the question: what should we do now? 1. Start moving irrelevant code out of libgit.a, and use inspiration from libgit2 to improve it (this might or might not involve taking code from libgit2). Get _users_ of libgit.a via ruby bindings (or something) asap, so it puts pressure on fixing it. 2. Wait indefinitely until libgit2.git magically becomes ready to be usable by git.git as-is. Then throw libgit.a out the window, and rewrite git.git to call into libgit2.a instead [*1*]. What you seem to be saying is 3. Work on libgit2 (and abandon git.git?) [*2*], or worse: 2. fc is in favor of 1. Unless you are in favor of _not_ improving libgit.a, don't stand in his way: you might personally think that it is a difficult (or impossible) task, but that's no reason to stop fc from trying. I personally think his goal is admirable, and I'm nobody to say that it cannot be done: therefore, I will review his patches and help him in whatever little way I can. [Footnote] *1* You have dismissed 1 as being unworkable, but do you realize how unrealistic this sounds? *2* git.git has _far_ more users and a _lot_ more contributors. Don't be unwelcoming to contributors by asking them to go away and work on something else. The three proprietary applications you have given as counter-examples (?) is not helping anyone. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 11:34 PM, Jeff King p...@peff.net 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 that I cannot show you the source code, but you may interested to know that libgit2 powers: 1. Microsoft's Visual Studio Tools for Git plugin 2. GitHub's native Mac and Windows clients (using Objective C and C# bindings); some operations still shell out to git where the functionality is not yet implemented in libgit2. 3. Parts of the web view of GitHub.com via Ruby bindings It is definitely not feature-complete when compared with git.git. But I do think it is in a state that is usable for quite a few tasks. That's not what a I asked. We have perl, and shell, and python, and ruby scripts in git.git, they all use 'git foo' commands to get things done. But to do that, forks are needed, many of them, constantly. The proposal was to use libgit2 to avoid such forks. Well, show me a *script* that does that and is worthy of inclusion to git.git, even if it's to contrib. I didn't ask for irrelevant 3rd parties, I asked for something worthy of inclusion into git.git, a script that does something useful using libgit2. Duy Nguyen seems to think it's easy to do that. I'm waiting. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 12:26 AM, Jeff King p...@peff.net 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 code to outweigh the (admittedly often useful) patches. 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. And the Linux kernel is the most successful software project in history by far. It's code that speaks. 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 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? 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 (both with respect to technical details, as well as to communication styles), and disrespectful of other people. Go back to my 261 commits, show me one that is unmindful of technical details. It is certainly your choice about how you will communicate. But likewise it is the choice of readers and reviewers to choose how much of their time to give to your writings. Exactly. Nobody is forcing you to read my emails. But somehow you already know that ignoring them is not in the best interest of the project. And by that I mean it's in the best interest of our users, without which our project is nothing. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 overrated, and proof of that the Linux kernel, where honest and straight talk is the bread and butter of the mailing list. And the Linux kernel is the most successful software project in history by far. It's code that speaks. 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 (both with respect to technical details, as well as to communication styles), and disrespectful of other people. While I agree that being rude and obstinate is definitely undesirable, and that a healthy on-list environment is important, I have something to add: Being super-tactful comes at a cost. Regulars on the mailing list have to spend 3~4x the amount of time to compose an email (reading and re-reading their drafts to see how to express them in a more friendly way); this leads to a lot of inefficiency and creates a suffocating environment in which people don't have freedom of expression. I would much rather prefer straight talk where nobody reads into what is written and takes offense. In this case, jrn took offense and talked about how he would ban fc from the list if he were managing it: while I'm not defending fc's tone, I'm not defending jrn's comment either. jrn has been around since mid-2008, and fc has been around since early-2009. It's mid-2013, and they still haven't learnt to work with each other. Disagreement is healthy, and is the foundation of progress. When it comes to sensitive issues, stern disagreement is often mis-interpreted as disrespect (or worse). If we keep beating up disagreements on the basis of tone and demeanor, git.git would go nowhere. Sure, it would be more ideal if fc's tone were friendlier [*1*], but it isn't: let's deal with the issue instead of constantly whining about it. [Footnotes] *1* Oh, and mine too. I've been told several times off-list that my tone is unfriendly. I'm working on fixing the issue, but I don't enjoy the constant suffocation: I should be able to say what I want without too much effort. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 7:48 AM, Ramkumar Ramachandra artag...@gmail.com 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 useful) patches. 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. And the Linux kernel is the most successful software project in history by far. It's code that speaks. 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 (both with respect to technical details, as well as to communication styles), and disrespectful of other people. While I agree that being rude and obstinate is definitely undesirable, and that a healthy on-list environment is important, I have something to add: Being super-tactful comes at a cost. Regulars on the mailing list have to spend 3~4x the amount of time to compose an email (reading and re-reading their drafts to see how to express them in a more friendly way); this leads to a lot of inefficiency and creates a suffocating environment in which people don't have freedom of expression. That's exactly the reason why they don't put emphasis on that in the Linux kernel mailing list. Besides, when something is really fucked up, the most effective way to convey the fact that you think it's totally fucked up, is to say precisely that. If somebody's feelings get hurt along the way, and they decide to leave the project, they were not cut for Linux development anyway. I would much rather prefer straight talk where nobody reads into what is written and takes offense. In this case, jrn took offense and talked about how he would ban fc from the list if he were managing it: while I'm not defending fc's tone, I'm not defending jrn's comment either. jrn has been around since mid-2008, and fc has been around since early-2009. It's mid-2013, and they still haven't learnt to work with each other. We don't _need_ to work with each other. If he helps the project, and I help the project, what's wrong with that? Disagreement is healthy, and is the foundation of progress. When it comes to sensitive issues, stern disagreement is often mis-interpreted as disrespect (or worse). If we keep beating up disagreements on the basis of tone and demeanor, git.git would go nowhere. Sure, it would be more ideal if fc's tone were friendlier [*1*], but it isn't: let's deal with the issue instead of constantly whining about it. Completely agree. Disagreement is not disrespect. Besides, ideas don't have feelings, ideas don't need respect; ideas should be criticized. Any rational person, specially scientists, understand that it's not healthy to have an emotional attachment to ideas; they might be wrong, and they need scrutiny. If one doesn't tolerate criticism of one's ideas (however straightforward or delicate it might be), one is never going to find the truth. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 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. Go back to my 261 commits, show me one that is unmindful of technical details. I do not have an interest in cataloguing past conflicts I and others have had with you; the list archive has done so. I have already made my comments there, and I see no point in starting a new argument. Exactly. Nobody is forcing you to read my emails. But somehow you already know that ignoring them is not in the best interest of the project. And by that I mean it's in the best interest of our users, without which our project is nothing. I never claimed that you contribute nothing. But every minute spent arguing with you is a minute that could be spent on something more productive. It is certainly possible that community members reading your emails could be a net negative for the users, if it leaves them no time for other code. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Jun 9, 2013 at 12:26 AM, Jeff King p...@peff.net 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 code to outweigh the (admittedly often
useful) patches.
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. And the Linux kernel is the most successful software
project in history by far. It's code that speaks.
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.
FWIW, I'll add my voice here.
In addition to what has been said by Jeff and Jonathan already (and with
which I agree), I would like to point out one observation about your
style of discussion that I find particularly unproductive.
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 the bigger issue. In effect you are
attempting to shift a significant burden of proof back to the other
party.
Case in point:
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 (both with respect to technical details, as well as to
communication styles), and disrespectful of other people.
Go back to my 261 commits, show me one that is unmindful of technical
details.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 applications have been made possible. Isn't it completely orthogonal to the discussion about how best to lib'ify git.git though? From what I understand, fc is not interested in building another application leveraging libgit.a or libgit2; he's interested in improving libgit.a and getting more users. Perhaps I misunderstood the discussion, but it looked to me that there was an assertion that libgit2 was not ready for useful work. I do not think that is true, and I tried to counter it with facts. If that was not useful to the discussion, I apologize for leading it astray. It is definitely not feature-complete when compared with git.git. But I do think it is in a state that is usable for quite a few tasks. What is this task you are discussing? You snipped the part of Felipe's message that I quoted: 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. I meant tasks that were equivalent to at least a couple of 'git foo' commands as performed by the programs I mentioned. Like cloning, checkout, commit, revision traversal, diffs, etc. fc is talking about improving libgit.a and getting an official git library with many users. Answer the question: what should we do now? I do not think I was addressing that point at all in my email. But since you ask... 1. Start moving irrelevant code out of libgit.a, and use inspiration from libgit2 to improve it (this might or might not involve taking code from libgit2). Get _users_ of libgit.a via ruby bindings (or something) asap, so it puts pressure on fixing it. 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 step at all. That is simply code that no library users would want to call, and is easy to deal with: move it out. The hard part is code that users _would_ want to call, and is totally broken. Patches dealing with that are the hard obstacle that people working in this direction would need to overcome. But I do not see any such patches under discussion. 2. Wait indefinitely until libgit2.git magically becomes ready to be usable by git.git as-is. Then throw libgit.a out the window, and rewrite git.git to call into libgit2.a instead [*1*]. I think the magically here could be work on libgit2 to move it towards being useful for git.git. I also do not think there needs to be a throw out libgit.a flag day. We can make a decision later to start adopting bits of libgit2 inside git.git (the big downside being an increased dependency). Maybe the code style will diverge too much and it will never be appropriate to do so. We'll have to see. What you seem to be saying is 3. Work on libgit2 (and abandon git.git?) [*2*], or worse: 2. I didn't say that at all. If the two projects co-exist forever, working compatibly on the same repositories, and git.git is the command line and libgit2 is the library, I do not see that as the end of the world. The downside there is is code duplication, which is why it may eventually make sense for libgit.a to start adopting bits of libgit2 (it is usually hard to go the other way, both for licensing reasons, and for the fact that the library code tends to be more reusable). fc is in favor of 1. Unless you are in favor of _not_ improving libgit.a, don't stand in his way: I'm not. I tried to give pointers on the path that I think would be useful (e.g., what would break with his ruby patch). *1* You have dismissed 1 as being unworkable, but do you realize how unrealistic this sounds? I don't think I dismissed it as unworkable. I said it was a lot of work, tried to describe some examples, and said that I think the other route may be _less_ work. *2* git.git has _far_ more users and a _lot_ more contributors. Don't be unwelcoming to contributors by asking them to go away and work on something else. The three proprietary applications you have given as counter-examples (?) is not helping anyone. They were counter-examples to the point libgit2 is not ready for real work, which I thought was being made. If that was not the point being made, then no, they are not helping anyone. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 12:53 PM, Thomas Rast tr...@inf.ethz.ch 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 the bigger issue. In effect you are attempting to shift a significant burden of proof back to the other party. He who makes a claim has the burden of proof. That which can be asserted without evidence, can be dismissed without evidence. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 (both with respect to technical details, as well as to communication styles), and disrespectful of other people. While I agree that being rude and obstinate is definitely undesirable, and that a healthy on-list environment is important, I have something to add: Being super-tactful comes at a cost. 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://article.gmane.org/gmane.comp.version-control.git/227053 sums up the core of many of the conflicts I've seen on the list. I am less interested in people's feelings than I am in discussions trying to reach a productive position of agreement, rather than turning it into a point by point debate that may no longer have any use for the project (sometimes individual points need to be refuted or discussed, of course, but it is easy to lose sight of the purpose of an email). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 12:55 PM, Jeff King p...@peff.net 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 LGPL, because of which these three proprietary applications have been made possible. Isn't it completely orthogonal to the discussion about how best to lib'ify git.git though? From what I understand, fc is not interested in building another application leveraging libgit.a or libgit2; he's interested in improving libgit.a and getting more users. Perhaps I misunderstood the discussion, but it looked to me that there was an assertion that libgit2 was not ready for useful work. I do not think that is true, and I tried to counter it with facts. That was not the point. Take 'contrib/related/git-related', or any useful script, and make it so it uses libgit2 instead of forking 'git foo' commands. It's not going to happen. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 step at all. That is simply code that no library users would want to call, and is easy to deal with: move it out. The hard part is code that users _would_ want to call, and is totally broken. Patches dealing with that are the hard obstacle that people working in this direction would need to overcome. But I do not see any such patches under discussion. Forget the rest; this makes it clear. Thanks, and sorry for all the confusion. So, reorganization is not the first step. Can you please post an example patch illustrating what needs to be done, so we can follow? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 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, so we agree that a project doesn't need a collegial work environment to be extremely and amazingly successful. No, I said that point 1 was the point I was not agreeing with. I do not have an opinion on 2, as I do not interact with the kernel community enough to know. In fact, any rational person would keep an open mind to the fact that perhaps it actually _helps_ to not have such environment, based on the evidence. In my experience, dealing with you has been a giant time sink. For example, this thread. Without needing to get into the exact definition of such an environment, the above statement is certainly my backed by empirical experience. 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, it's not backed by evidence, merely by your subjective experience. And memory is a pretty bad indicator of reality. I think this thread is an excellent example all by itself. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 1:06 PM, Ramkumar Ramachandra artag...@gmail.com 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 think that moving code in and out of libgit.a is an important first step at all. That is simply code that no library users would want to call, and is easy to deal with: move it out. The hard part is code that users _would_ want to call, and is totally broken. Patches dealing with that are the hard obstacle that people working in this direction would need to overcome. But I do not see any such patches under discussion. Forget the rest; this makes it clear. Thanks, and sorry for all the confusion. So, reorganization is not the first step. Can you please post an example patch illustrating what needs to be done, so we can follow? If you have a code-base with 100 functions, 10 of which make sense in a public library, instead of going ahead to fix those 10 functions, it makes sense to *first* separate those 10 functions, and *then* clean them up for public usage. But let's assume that Jeff is right and this is not the first step. It doesn't matter; I already started that step and created builtin/lib.a. Are you going to throw away that because it's not the first step? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 1:10 PM, Jeff King p...@peff.net 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, it's not backed by evidence, merely by your subjective experience. And memory is a pretty bad indicator of reality. I think this thread is an excellent example all by itself. It's an excellent example of your personal issues clouding your judgement. The topic was this (which you just snipped): 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 details? It's not. There are no technical details I was unmindful of in this thread. Once more, you have no evidence of that claim. Only subjective personal experience. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 I do not think that moving code in and out of libgit.a is an important first step at all. That is simply code that no library users would want to call, and is easy to deal with: move it out. The hard part is code that users _would_ want to call, and is totally broken. Patches dealing with that are the hard obstacle that people working in this direction would need to overcome. But I do not see any such patches under discussion. Forget the rest; this makes it clear. Thanks, and sorry for all the confusion. So, reorganization is not the first step. Can you please post an example patch illustrating what needs to be done, so we can follow? 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. For the record, I am not _against_ any code organization that might be useful for lib-ification later. I just do not see it as an interesting step to be discussing if you want to know whether such a lib-ification effort is feasible. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 1:22 PM, Jeff King p...@peff.net 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 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 step at all. That is simply code that no library users would want to call, and is easy to deal with: move it out. The hard part is code that users _would_ want to call, and is totally broken. Patches dealing with that are the hard obstacle that people working in this direction would need to overcome. But I do not see any such patches under discussion. Forget the rest; this makes it clear. Thanks, and sorry for all the confusion. So, reorganization is not the first step. Can you please post an example patch illustrating what needs to be done, so we can follow? 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. Wouldn't it make sense then to concentrate on the patches that we do have? For the record, I am not _against_ any code organization that might be useful for lib-ification later. I just do not see it as an interesting step to be discussing if you want to know whether such a lib-ification effort is feasible. If you don't find it interesting, don't do it. I already did this step (Move sequencer to builtin), the question is; does it go forward, or should it be rejected? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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://article.gmane.org/gmane.comp.version-control.git/227053
sums up the core of many of the conflicts I've seen on the list.
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 with no end in sight. WHAT do we do?
I'll be frank: I'm a pragmatic person, and I want to see work.
Despite all this mess, who has shown me the most number of patches
with some direction? Felipe. Who gets the most number of patches
into git.git, by far? Felipe. And who is wasting time theorizing
about what's wrong with Felipe in various ways? Everyone else.
I am less interested in people's feelings than I am in discussions
trying to reach a productive position of agreement, rather than turning
it into a point by point debate that may no longer have any use for the
project (sometimes individual points need to be refuted or discussed, of
course, but it is easy to lose sight of the purpose of an email).
Felipe has discussed the {sequencer.c - builtin/sequencer.c} move
with a bunch of us (and sent a patch), discussed how to write tests
properly with me (with a patch), and discussed how ruby can be used to
call into libgit.a (with code that I'm currently playing with).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 nothing, no? For the record, I am not _against_ any code organization that might be useful for lib-ification later. I just do not see it as an interesting step to be discussing if you want to know whether such a lib-ification effort is feasible. Then whom are we to ask about this feasibility? All the core contributors (including Junio) are in the CC. Nobody has said anything. So, are you proposing that we sit and ponder over our theoretically-indeterminate-feasibility problem? There is no magic bullet, Jeff. We write code, and we fix bugs as and when they crop up; there's really not much else anyone can do. Help by writing code, or reviewing someone else's code. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 with no end in sight. WHAT do we do? My advice would be to ignore him when the discussion proceeds in an unproductive direction. But I never wanted to tell other people what to do with respect to Felipe. My point was to express public agreement with Jonathan, and show that individual members of the community may be less interested in helping you if you behave in certain ways. At this point, I do not have any hope of impacting Felipe's behavior, but I thought it might be demonstrative to other list members. 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]. -Peff [1] Or maybe not. Maybe there are enough people interested in what Felipe has to say that he will continue to get review. I even try to review his patches myself when there is something factually and obviously wrong to point out, and it won't suck me into a time-wasting argument that goes nowhere. But the point is that each individual can make the choice themselves, and then the problem is solved for them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 1:32 PM, Ramkumar Ramachandra artag...@gmail.com 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
productive direction. I found Thomas's comment here:
http://article.gmane.org/gmane.comp.version-control.git/227053
sums up the core of many of the conflicts I've seen on the list.
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 with no end in sight. WHAT do we do?
What really puzzles me is that I think discussion and disagreement are
healthy, not only in open source projects, but in any organization; If
everyone always agrees, you know something is really wrong. But if
others think disagreement is not helpful, why do they bother replying
at all? Arguing. And they think their time is better spent not
discussing, but writing code (or something else), why don't they spend
their time that way. Why blame me for their choices?
We disagree, that's fine, move on.
I'll be frank: I'm a pragmatic person, and I want to see work.
Despite all this mess, who has shown me the most number of patches
with some direction? Felipe. Who gets the most number of patches
into git.git, by far? Felipe. And who is wasting time theorizing
about what's wrong with Felipe in various ways? Everyone else.
Thanks! Talk is cheap, show me the code.
I am less interested in people's feelings than I am in discussions
trying to reach a productive position of agreement, rather than turning
it into a point by point debate that may no longer have any use for the
project (sometimes individual points need to be refuted or discussed, of
course, but it is easy to lose sight of the purpose of an email).
Felipe has discussed the {sequencer.c - builtin/sequencer.c} move
with a bunch of us (and sent a patch), discussed how to write tests
properly with me (with a patch), and discussed how ruby can be used to
call into libgit.a (with code that I'm currently playing with).
Interesting. In case it might help you, this is the extconf.rb I used:
---
ruby/extconf.rb:
#!/usr/bin/env ruby
require 'mkmf'
$INCFLAGS = -I.. #{$INCFLAGS}
$CFLAGS += -DSHA1_HEADER='openssl/sha.h'
# libs
$LOCAL_LIBS += ' ../builtin/lib.a ../libgit.a ../xdiff/lib.a'
$LIBS += ' -lssl -lcrypto -lz'
# make sure there are no undefined symbols
$LDFLAGS += ' -Wl,--no-undefined'
# Create Makefile
dir_config('git')
create_makefile('git')
--
I have to build all the objects with -fPIC though.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 forward. Nobody said that it is the theoretical best, but it's _much_ better than doing nothing, no? I thought I already said: there is a lot of global state that is assumed to be wiped between various functions and git commands. For example, you cannot just call cmd_log twice in the same process and get the right answers. I haven't seen a proposal for dealing with that. Then whom are we to ask about this feasibility? All the core contributors (including Junio) are in the CC. Nobody has said anything. So, are you proposing that we sit and ponder over our theoretically-indeterminate-feasibility problem? There is no magic bullet, Jeff. We write code, and we fix bugs as and when they crop up; there's really not much else anyone can do. Help by writing code, or reviewing someone else's code. I mentioned a bug above. How are you going to fix it? Where is your patch to review? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Jun 9, 2013 at 1:10 PM, Jeff King p...@peff.net 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 details? It's not. There are no technical details I was unmindful of in this thread. Ok, I'll bite (against my better judgment). From a related thread, a few minutes ago: On Sun, Jun 9, 2013 at 7:46 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Jun 9, 2013 at 12:32 PM, Thomas Rast tr...@inf.ethz.ch wrote: So you would deliberately break a bisection on this test file? No, this patch series won't be applied. Thomas points out a technical detail with the patch series, and the answer given is 100% non-constructive. 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. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
Ramkumar Ramachandra artag...@gmail.com 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 Thomas's comment here:
http://article.gmane.org/gmane.comp.version-control.git/227053
sums up the core of many of the conflicts I've seen on the list.
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 with no end in sight. WHAT do we do?
I'll be frank: I'm a pragmatic person, and I want to see work.
Despite all this mess, who has shown me the most number of patches
with some direction? Felipe. Who gets the most number of patches
into git.git, by far? Felipe. And who is wasting time theorizing
about what's wrong with Felipe in various ways? Everyone else.
At what cost?
The arguments arise to a large degree from attempting to review his
work. Not doing so is not an option, see e.g.:
http://article.gmane.org/gmane.comp.version-control.git/223279
http://article.gmane.org/gmane.comp.version-control.git/225969
http://article.gmane.org/gmane.comp.version-control.git/226125
And that's not even counting the part of the argument that arises purely
from deliberate flaunting of the project's guidelines.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 2:11 PM, Johan Herland jo...@herland.net wrote: On Sun, Jun 9, 2013 at 8:16 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Jun 9, 2013 at 1:10 PM, Jeff King p...@peff.net 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 details? It's not. There are no technical details I was unmindful of in this thread. Ok, I'll bite (against my better judgment). From a related thread, a few minutes ago: On Sun, Jun 9, 2013 at 7:46 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Jun 9, 2013 at 12:32 PM, Thomas Rast tr...@inf.ethz.ch wrote: So you would deliberately break a bisection on this test file? No, this patch series won't be applied. Thomas points out a technical detail with the patch series, and the answer given is 100% non-constructive. Geezus! http://thread.gmane.org/gmane.comp.version-control.git/227109 There. Are you happy? I dropped the patches that are not part of the series. Who benefits from this? NOBODY. Certainly not the users. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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's tone, demeanour and style of discussion. It has been discussed a zillion times now. You're doing it under the pretext of agreement and setting a good example (in jk's words); in reality, you're setting a bad example by showing everyone that it is okay to do the same thing (welcome jh!) and waste everyone's time. http://article.gmane.org/gmane.comp.version-control.git/223279 http://article.gmane.org/gmane.comp.version-control.git/225969 http://article.gmane.org/gmane.comp.version-control.git/226125 All these are legitimate reviews, and they and everyone's getting along just fine. What argument are you talking about? *scratches head* And that's not even counting the part of the argument that arises purely from deliberate flaunting of the project's guidelines. What guidelines? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 applied (which often don't have self-contained descriptions, sadly) and the context of other patches. 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. One of an addict's friends might confront her and try to help her understand that things have gone too far. Another friend says, What a mess. Let's go to a bar and talk and they are drinking again. The usual approach for avoiding this is an intervention, where a large group of people that care about a person together agree to confront the addict and make sure she actually understands and work together to find a real way out. 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. Ramkumar Ramachandra wrote: I'll be frank: I'm a pragmatic person, and I want to see work. Despite all this mess, who has shown me the most number of patches with some direction? Felipe. Who gets the most number of patches into git.git, by far? Felipe. And who is wasting time theorizing about what's wrong with Felipe in various ways? Everyone else. In that case, I can see a simple solution. Felipe, who provides the most patches in git.git, by far (I don't know what that means, but I'll take it as an assumption), can put up a fork of git that you run. He can solicit whatever level of review he is comfortable with before pushing out changes, and then the result is available, without the pesky middle-man of those theorizers that were trying to develop git a different way and then got annoyed. No harm done, right? It doesn't have to involve the list, because what's relevant in this worldview is code, not the people. So why aren't I privately ignoring his messages and letting the list become what it may? It would seem that I'm making the problem much worse, by starting discussions that focus of how to stop pushing other contributors away instead of (what's important) code! Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 2:54 PM, Ramkumar Ramachandra artag...@gmail.com 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, but at least there's a patch that essentially tackles what I tried to tackle. So it's good for the users. http://article.gmane.org/gmane.comp.version-control.git/226125 This also evolved rather nicely, since there is discussion about exactly how the signals should be presented to Windows users, because it's clear currently most of the codes only work in Linux. Again, users benefit from this. http://article.gmane.org/gmane.comp.version-control.git/223279 Unfortunately nobody took the charge on this ones, so we will remain forever in a non-ideal situation. It's not my fault though. I sent the patch that fixes the problem, and there's only so much I can do. Not that it matters much, because the important patches were applied. But what does this have to do with anything? How are you helping the Git project by bringing this up? How does this help our users? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 2:57 PM, Jonathan Nieder jrnie...@gmail.com 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 that can enable me is Junio. If he stops merging my patches I would stop sending them. It appears Junio is a good maintainer though, as he puts the needs of the project, and thus our users, above your personal issues. I'll be frank: I'm a pragmatic person, and I want to see work. Despite all this mess, who has shown me the most number of patches with some direction? Felipe. Who gets the most number of patches into git.git, by far? Felipe. And who is wasting time theorizing about what's wrong with Felipe in various ways? Everyone else. In that case, I can see a simple solution. Felipe, who provides the most patches in git.git, by far (I don't know what that means, but I'll take it as an assumption), Maybe this will help understand the meaning of that: % git shortlog -n -s --no-merges --since '3 months ago' 221 Felipe Contreras 83 Junio C Hamano 71 Jeff King 62 Michael Haggerty 48 Ramkumar Ramachandra 35 Thomas Rast 33 Nguyễn Thái Ngọc Duy 32 John Keeping 30 René Scharfe 23 Kevin Bracey -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 project standards, and your eternal argumentativeness outweigh the benefit of your contributions, large though they may be. Writing code is only a small part of keeping the Git project going. * Reviewing code is an essential, more thankless, and therefore more precious, contribution. Therefore the Git project has standards to make code review less unpleasant and more effective; for example: (1) patches shouldn't cause regressions; (2) commit messages have to be written to very high standards; (3) reviewers' comments should be accepted gratefully and taken very seriously. Almost everybody in the Git community accepts these standards. Felipe, you do not seem to. The result is that reviewers' time and goodwill are wasted, and they justifiably feel unvalued. We can't afford to misuse reviewers; they are the bedrock (and the bottleneck) of the project. * Gaining and keeping contributors is important to maintaining the success of the project. The mailing list is the main forum for the development community; therefore, it is important that the mailing list be a place where people display a high degree of technical excellence, but also respect for one another, friendliness (or at least a lack of hostility), and discussions that do turn into flame wars. It is possible to have a profound technical disagreement without losing respect for the other side; contrariwise it is NOT acceptable to twist a technical disagreement into a personal attack, even by the slightest insinuation. Felipe, in my opinion your participation in the mailing list lowers the tone dramatically, and will result in loss of other contributors and the failure to attract new contributors. Felipe, I wish that you would devote a small fraction of your prodigious energy to the very difficult challenge of feeling empathy, understanding, and respect for the other members of the community. But if things continue the way they have, I personally would, with sadness in my heart, prefer to forgo your patches in exchange for the more important benefit of a more collegial (and therefore overall more productive and sustainable) community. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
[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 impression of these discussion threads. I also agree. In my opinion, Felipe, your abrasiveness, your disregard of project standards, and your eternal argumentativeness outweigh the benefit of your contributions, large though they may be. Writing code is only a small part of keeping the Git project going. * Reviewing code is an essential, more thankless, and therefore more precious, contribution. Therefore the Git project has standards to make code review less unpleasant and more effective; for example: (1) patches shouldn't cause regressions; (2) commit messages have to be written to very high standards; (3) reviewers' comments should be accepted gratefully and taken very seriously. Almost everybody in the Git community accepts these standards. Felipe, you do not seem to. The result is that reviewers' time and goodwill are wasted, and they justifiably feel unvalued. We can't afford to misuse reviewers; they are the bedrock (and the bottleneck) of the project. * Gaining and keeping contributors is important to maintaining the success of the project. The mailing list is the main forum for the development community; therefore, it is important that the mailing list be a place where people display a high degree of technical excellence, but also respect for one another, friendliness (or at least a lack of hostility), and discussions that do turn into flame wars. It is possible to have a profound technical disagreement without losing respect for the other side; contrariwise it is NOT acceptable to twist a technical disagreement into a personal attack, even by the slightest insinuation. Felipe, in my opinion your participation in the mailing list lowers the tone dramatically, and will result in loss of other contributors and the failure to attract new contributors. Felipe, I wish that you would devote a small fraction of your prodigious energy to the very difficult challenge of feeling empathy, understanding, and respect for the other members of the community. But if things continue the way they have, I personally would, with sadness in my heart, prefer to forgo your patches in exchange for the more important benefit of a more collegial (and therefore overall more productive and sustainable) community. Michael FWIW, from the meager but I hope not utterly irrelevant point of view of a non-contrib-but-not-clueless user as I am: *a complete and hear-felt +1 on what Michael said here* Until a couple of months ago, skimming this list was mostly a real pleasure, and would often give me some valuable insight on the upcoming features/incompatibilities of Git, help me organize my own workflow as a Git user, and also steadily improve my understanding and command of netiquette in both generic mailing lists and Open Source and/or Free Software communities. Now, when I open my mail and get to the git folder, I more and more end up asking myself: 1. What kind of flame am I going to have to see today?; and 2. How much chaff will I have to navigate through to finally to get to interesting stuff (if any is actually left)? *To reiterate:* Sadly, the environment of the Git mailing list has been steadily and slowly *sinking* -- sinking from being pleasant and useful and even educational, into being annoying and frustrating and often somewhat toxic. I usually jeer and despise he who makes public accusations by simply adding his voice to the disapproval of the community, but this time, I feel compelled to do exactly that: 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. Sorry for the extra potential controversy, but sometimes one has to speak up, Stefano -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 4:42 PM, Michael Haggerty mhag...@alum.mit.edu 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 somehow I like the same things as you; to be treated nicely. I don't. understanding, and respect for the other members of the community. Respect is not automatic. But if things continue the way they have, I personally would, with sadness in my heart, prefer to forgo your patches in exchange for the more important benefit of a more collegial (and therefore overall more productive and sustainable) community. In other words; you prefer to talk to people that have a similar mind than you, and avoid doing what the project actually needs; code. I wrote tons of code that help the project. And you avoid that because what? Can you put the needs of the project about your personal need for others to be nice towards you? -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini stefano.lattar...@gmail.com 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 and not the others who have as much fault if not more. You need two sides to have an argument. The difference is; I did actually send code. Code that is good, code that works, and code that users need. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras felipe.contre...@gmail.com 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 maybe more). Why make an exception for sequencer? Why not? What do we gain from this? Organization. A lot of code in libgit.a is only used by builtin commands, e.g. fetch-pack.c, should we move it to? Yes. I ask because I moved fetch-pack from builtin out because of linking issues and I don't want the same happen to sequencer.c. I'm sure those linking issues can be solved. I don't see why libgit.a couldn't eventually be the same as libgit2. We need better organization tough (e.g. builtins/lib.a). If you are arguing favor of a more messy setup, then we should link all the builtin/*.o to libgit.a, because the current situation just doesn't cut it. For example, init_copy_notes_for_rewrite() cannot be accessed by sequencer.c, and while it's possible to move that function (and others) to libgit.a, it doesn't make sense, because it can only be used by builtins. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras felipe.contre...@gmail.com 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 maybe more). Why make an exception for sequencer? Why not? And while we are at why not, why don't you fork git? I ask because I moved fetch-pack from builtin out because of linking issues and I don't want the same happen to sequencer.c. I'm sure those linking issues can be solved. Yeah, I scratched my head for hours and finally gave in. Maybe you are better at the toolchain than me. I don't see why libgit.a couldn't eventually be the same as libgit2. We need better organization tough (e.g. builtins/lib.a). If you are arguing favor of a more messy setup, then we should link all the builtin/*.o to libgit.a, because the current situation just doesn't cut it. For example, init_copy_notes_for_rewrite() cannot be accessed by sequencer.c, and while it's possible to move that function (and others) to libgit.a, it doesn't make sense, because it can only be used by builtins. 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. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras felipe.contre...@gmail.com 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 maybe more). Why make an exception for sequencer? Why not? And while we are at why not, why don't you fork git? That's not an answer. I ask because I moved fetch-pack from builtin out because of linking issues and I don't want the same happen to sequencer.c. I'm sure those linking issues can be solved. Yeah, I scratched my head for hours and finally gave in. Maybe you are better at the toolchain than me. I gave it a try, but transport.c needs fetch_pack(), and transport does belong in libgit.a, so fetch_pack() belongs there too. This is not the case for sequencer.c. I don't see why libgit.a couldn't eventually be the same as libgit2. We need better organization tough (e.g. builtins/lib.a). If you are arguing favor of a more messy setup, then we should link all the builtin/*.o to libgit.a, because the current situation just doesn't cut it. For example, init_copy_notes_for_rewrite() cannot be accessed by sequencer.c, and while it's possible to move that function (and others) to libgit.a, it doesn't make sense, because it can only be used by builtins. libgit.a is just a way of grouping a bunch of objects together, not a real library That's what a library is. and not meant to be. If you aim something more organized, please show at least a roadmap what to move where. I already did that; we move code from libgit.a to builtin/*.o until libgit.a == libgit2. Done. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras felipe.contre...@gmail.com 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 maybe more). Why make an exception for sequencer? Why not? And while we are at why not, why don't you fork git? That's not an answer. Neither is Why not? and not meant to be. If you aim something more organized, please show at least a roadmap what to move where. I already did that; we move code from libgit.a to builtin/*.o what code besides sequencer.c? 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. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 never an extensive on-list discussion about why git.git cannot be lib'ified. The first appearance of libgit2 is here [1]. I briefly read through the initial history of libgit2.git too, but I cannot find a single discussion detailing why lib'ifying git.git is fundamentally unworkable (there's some vague mention of global state baggage and presence of die(), but that's about it). Unless you can point to some detailed discussions, or write out a really good reason yourself, I don't think there's any harm in letting fc try. Ofcourse, he still indicated any sort of plan yet, and I'm also waiting for that. [1]: http://thread.gmane.org/gmane.comp.version-control.git/99608 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 7:55 PM, Ramkumar Ramachandra artag...@gmail.com 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 different definition of == than I do. As far as I know, there was never an extensive on-list discussion about why git.git cannot be lib'ified. The first appearance of libgit2 is here [1]. I briefly read through the initial history of libgit2.git too, but I cannot find a single discussion detailing why lib'ifying git.git is fundamentally unworkable (there's some vague mention of global state baggage and presence of die(), but that's about it). Unless you can point to some detailed discussions, or write out a really good reason yourself, I don't think there's any harm in letting fc try. Ofcourse, he still indicated any sort of plan yet, and I'm also waiting for that. [1]: http://thread.gmane.org/gmane.comp.version-control.git/99608 Hm.. I thought Shawn wrote a bit more in that mail. Apparently I was wrong. I think it's discuessed in the list from time to time (otherwise I wouldn't know) but I don't keep bookmarks. I _think_ the reason is because git was never written as a reusable library in mind from the beginning. So global states and die() exist. Worse, run once and let the OS clean eveything up at process exit leads to some deliberate memory leak if it's made a library. See alloc.c for example. The internal API is not really designed to be usuable/stable as a library. All of these made it very hard to convert the current code base into a true library. So the effort was put into creating a new library instead, copying code from git code base over when possible. 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. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 7:34 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 7:25 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Jun 8, 2013 at 6:42 AM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:14 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Fri, Jun 7, 2013 at 9:35 PM, Duy Nguyen pclo...@gmail.com wrote: On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras felipe.contre...@gmail.com 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 maybe more). Why make an exception for sequencer? Why not? And while we are at why not, why don't you fork git? That's not an answer. Neither is Why not? The answer is the rest of the e-mail. and not meant to be. If you aim something more organized, please show at least a roadmap what to move where. I already did that; we move code from libgit.a to builtin/*.o what code besides sequencer.c? A roadmap doesn't require code. If you truly think that there's nothing else that is specific to builtins; alias.c. 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. Are you being obtuse on purpose? It doesn't matter how different libgit.a and libgit2 currently are, there's always a path from one code-base to another. Unless libgit2 has code for builtin commands, the first step would invariably be to move the code that is specific for builtins to builtin/*.o. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 8:15 AM, Duy Nguyen pclo...@gmail.com 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 to move libgit2 closer to libgit.a, and libgit.a closer to libgit2, both at the same time. I have rewritten a lot of code using this strategy. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 once and let the OS clean eveything up at process exit leads to some deliberate memory leak if it's made a library. See alloc.c for example. The internal API is not really designed to be usuable/stable as a library. All of these made it very hard to convert the current code base into a true library. So the effort was put into creating a new library instead, copying code from git code base over when possible. 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 into git-core, to make scripting more sane than shell-spawning everything like brutes. I think this is what fc is aiming at, atleast in the foreseeable future. As far as long-running server-side implementations go, I think jgit is the way forward (sop is more interested in that now, I believe). libgit2 might work for GitHub now, but I don't know if they will be forced to move to the jvm in the future. 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. Please look at the code in libgit2.git briefly. It's _very_ different from git.git, and the amount of glue code that would be needed to piece them together is unfathomable. There are no git.git contributors committing to libgit2.git, or vice-versa. libgit2 is primarily developed by vmg, cmn, and (more recently) rb. It's quite an active project that's diverging from the git.git design with every passing day. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 8:34 AM, Ramkumar Ramachandra artag...@gmail.com 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 impossible to do now? Nothing is impossible. My feeling is that no Git developers are interested in libgit2, so the idea of me contributing to libgit2 and leave libgit.a alone is more like a we don't want no reorganization. Then wait until libgit2 is ready before considering using it in Git's core, but that's never going to happen if we don't first start to bring the two code-bases closer together. IOW; sweep the issue under the carpet. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 8:34 PM, Ramkumar Ramachandra artag...@gmail.com 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 into git-core, to make scripting more sane than shell-spawning everything like brutes. I think this is what fc is aiming at, atleast in the foreseeable future. It's technically possible. You can already call into libgit.a as fc demonstrated with his ruby binding. Assuming that you are willing to dig in and fix all the problems (in a non-intrusive way) when a call into libgit.a does not work, there's still API issue. Do we want to freeze libgit.a API so that scripts will not be audited and changed unncessarily? Freezing the API at cmd_* level loses a lot of flexibility. Freezing at lower level may prevent us from making some changes. I still think that binding new languages to a clean library like libgit2 is better than to libgit.a. Just thinking of what might work and what might not is already a headache. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 9:10 AM, Duy Nguyen pclo...@gmail.com 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 libgit2 is better than to libgit.a. Just thinking of what might work and what might not is already a headache. 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. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 of a more organized source tree (so ls output can be less intimidating --- see Nico Pitre's mail on this a while ago for more hints), but randomly moving files one at a time to builtin/ destroys consistency and just makes things *worse*. So if you'd like to work on this, you'll need to start with a description of the endpoint, to help people work with you to ensure it is something consistent and usable. Actually, Felipe, I doubt that would work well. This project requires understanding how a variety of people use the git source code, which requires listening carefully to them and not alienating them so you can find out what they need. Someone good at moderating a discussion could do that on-list, but based on my experience of how threads with you go, a better strategy might be to cultivate a wiki page somewhere with a plan and give it some time (a month, maybe) to collect input. NAK to changing the meaning of builtin/ to built-in commands, plus sequencer, which seriously hurts consistency. Sincerely, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 11:49 AM, Jonathan Nieder jrnie...@gmail.com 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 are some rough plans I would like to help with in the direction of a more organized source tree (so ls output can be less intimidating --- see Nico Pitre's mail on this a while ago for more hints), but randomly moving files one at a time to builtin/ destroys consistency and just makes things *worse*. So if you'd like to work on this, you'll need to start with a description of the endpoint, to help people work with you to ensure it is something consistent and usable. So lets stash everything together. --- a/Makefile +++ b/Makefile @@ -990,6 +990,8 @@ BUILTIN_OBJS += builtin/verify-pack.o BUILTIN_OBJS += builtin/verify-tag.o BUILTIN_OBJS += builtin/write-tree.o +LIB_OBJS += $(BUILTIN_OBJS) + GITLIBS = $(LIB_FILE) $(XDIFF_LIB) EXTLIBS = @@ -1712,9 +1714,9 @@ git.sp git.s git.o: EXTRA_CPPFLAGS = \ '-DGIT_MAN_PATH=$(mandir_relative_SQ)' \ '-DGIT_INFO_PATH=$(infodir_relative_SQ)' -git$X: git.o GIT-LDFLAGS $(BUILTIN_OBJS) $(GITLIBS) +git$X: git.o GIT-LDFLAGS $(GITLIBS) $(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \ - $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS) + $(ALL_LDFLAGS) $(LIBS) help.sp help.s help.o: common-cmds.h @@ -1892,7 +1894,7 @@ VCSSVN_OBJS += vcs-svn/svndiff.o VCSSVN_OBJS += vcs-svn/svndump.o TEST_OBJS := $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS)) -OBJECTS := $(LIB_OBJS) $(BUILTIN_OBJS) $(PROGRAM_OBJS) $(TEST_OBJS) \ +OBJECTS := $(LIB_OBJS) $(PROGRAM_OBJS) $(TEST_OBJS) \ $(XDIFF_OBJS) \ $(VCSSVN_OBJS) \ git.o And stop any delusions that libgit.a has any meaning at all, and along the way get rid of any hopes of ever having an official public library similar to libgit2. Actually, Felipe, I doubt that would work well. This project requires understanding how a variety of people use the git source code, which requires listening carefully to them and not alienating them so you can find out what they need. My patch covers every need. Nobody has come forward with a reason not to organize the object files. Everything works after my patch the same way it has worked before. Someone good at moderating a discussion could do that on-list, but based on my experience of how threads with you go, a better strategy might be to cultivate a wiki page somewhere with a plan and give it some time (a month, maybe) to collect input. This has nothing to do with better strategy, it has everything to do with gut feelings and tradition. Not reasons. NAK to changing the meaning of builtin/ to built-in commands, plus sequencer, which seriously hurts consistency. Then apply the patch above and stop wasting our time with a library. Git is nothing but a bunch of disorganized object files, all squashed together, there's no library, nor will ever be; libgit.a is a misnomer. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 style does more harm than good. If I were maintaining git, I'd still accept your contributions, waiting until times when I had more patience to read them and sending them to the list when appropriate to get more feedback. Of course I am neither managing the list nor maintaining git, but I thought I should put that out there... Annoyed, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder jrnie...@gmail.com 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 that comment to you; you took the pellet and threw it at yourself. Moreover, following gut feelings and traditions without reason is not an insult, that's what human beings do. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 12:34 PM, Jonathan Nieder jrnie...@gmail.com 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 than anybody else[1], and you would ban me because you don't like my words? At the end of the day the project has benefited from my patches, and a wise maintainer would do what is best for the project. If you don't like my words, ignore them. Taking things personal is more often than not the wrong thing to do. Specially when they were not even directed to you. [1] https://www.ohloh.net/p/git/contributors?query=sort=commits_12_mo -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 is harmful enough to the code to outweigh the (admittedly often useful) patches. But I am not the mailing list owner, so what I would do is not too important. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 8:40 PM, Jonathan Nieder jrnie...@gmail.com 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'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 overrated, and proof of that the Linux kernel, where honest and straight talk is the bread and butter of the mailing list. And the Linux kernel is the most successful software project in history by far. It's code that speaks. And I have not destroyed anything, except maybe your sense of fairness and balance when reviewing my patches, but that is not my fault. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 working on the kernel are quite sensible and friendly on-list. Probably you are referring to some high-profile cases of flames, which perhaps I have just been lucky to avoid. I do not think the way the list works normally is a counterexample to common decency being useful. So no, I don't find But they are mean, and look how well they are doing! to be a compelling argument here. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 10:21 PM, Jonathan Nieder jrnie...@gmail.com 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 the topic at hand: For what it's worth, in my experience the people working on the kernel are quite sensible and friendly on-list. They are professional. When they need to be straight-forward, they are, even if that hurts the feelings of the colleagues. Probably you are referring to some high-profile cases of flames, No, I'm not. Heated discussions happen all the time, specially when the issue at hand is important. I do not think the way the list works normally is a counterexample to common decency being useful. Of course you wouldn't, but you are purposely ignoring the facts. The Linux kernel mailing lists concentrates on *the code*; he who writes the code has a voice, he who only has words doesn't. Personal beefs are not relevant. When there's something horribly wrong with the code, so are the responses. So no, I don't find But they are mean, and look how well they are doing! to be a compelling argument here. Because you dismiss the premise a priori. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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 interested to know that libgit2 powers: 1. Microsoft's Visual Studio Tools for Git plugin 2. GitHub's native Mac and Windows clients (using Objective C and C# bindings); some operations still shell out to git where the functionality is not yet implemented in libgit2. 3. Parts of the web view of GitHub.com via Ruby bindings It is definitely not feature-complete when compared with git.git. But I do think it is in a state that is usable for quite a few tasks. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
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. 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. And the Linux kernel is the most successful software project in history by far. It's code that speaks. 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. 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 (both with respect to technical details, as well as to communication styles), and disrespectful of other people. You have accused others of assuming you make comments in bad faith. Perhaps it is true that you are very pleasant and easy to work with in person, but in my opinion that is not the case, at least by email. I may be wrong, of course, and I certainly do not claim to be perfect myself. But I find it telling that many of the list participants seem to have had conflicts with you, and not with anyone else. So perhaps you may want to reconsider your style of communication. Unlike Jonathan, I would not ban you from the list. I do not believe in censoring anybody who is not a direct and constant nuisance (like a spammer). But personally I have a limited capacity for discussion with you, as it seems to have a knack for going back and forth, consuming a lot of time, and ending nowhere productive. It is certainly your choice about how you will communicate. But likewise it is the choice of readers and reviewers to choose how much of their time to give to your writings. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Move sequencer to builtin
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 felipe.contre...@gmail.com --- Makefile | 9 ++--- sequencer.c = builtin/sequencer.c | 0 sequencer.h = builtin/sequencer.h | 0 3 files changed, 6 insertions(+), 3 deletions(-) rename sequencer.c = builtin/sequencer.c (100%) rename sequencer.h = builtin/sequencer.h (100%) diff --git a/Makefile b/Makefile index 03524d0..d28bf7f 100644 --- a/Makefile +++ b/Makefile @@ -583,7 +583,8 @@ TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X)) # List built-in command $C whose implementation cmd_$C() is not in # builtin/$C.o but is linked in as part of some other command. -BUILT_INS += $(patsubst builtin/%.o,git-%$X,$(BUILTIN_OBJS)) +BUILT_INS_OBJS = $(filter-out $(BUILTIN_HELPER_OBJS),$(BUILTIN_OBJS)) +BUILT_INS += $(patsubst builtin/%.o,git-%$X,$(BUILT_INS_OBJS)) BUILT_INS += git-cherry$X BUILT_INS += git-cherry-pick$X @@ -714,7 +715,6 @@ LIB_H += resolve-undo.h LIB_H += revision.h LIB_H += run-command.h LIB_H += send-pack.h -LIB_H += sequencer.h LIB_H += sha1-array.h LIB_H += sha1-lookup.h LIB_H += shortlog.h @@ -856,7 +856,6 @@ LIB_OBJS += resolve-undo.o LIB_OBJS += revision.o LIB_OBJS += run-command.o LIB_OBJS += send-pack.o -LIB_OBJS += sequencer.o LIB_OBJS += server-info.o LIB_OBJS += setup.o LIB_OBJS += sha1-array.o @@ -894,6 +893,8 @@ LIB_OBJS += wt-status.o LIB_OBJS += xdiff-interface.o LIB_OBJS += zlib.o +BUILTIN_HELPER_OBJS += builtin/sequencer.o + BUILTIN_OBJS += builtin/add.o BUILTIN_OBJS += builtin/annotate.o BUILTIN_OBJS += builtin/apply.o @@ -990,6 +991,8 @@ BUILTIN_OBJS += builtin/verify-pack.o BUILTIN_OBJS += builtin/verify-tag.o BUILTIN_OBJS += builtin/write-tree.o +BUILTIN_OBJS += $(BUILTIN_HELPER_OBJS) + GITLIBS = $(LIB_FILE) $(XDIFF_LIB) EXTLIBS = diff --git a/sequencer.c b/builtin/sequencer.c similarity index 100% rename from sequencer.c rename to builtin/sequencer.c diff --git a/sequencer.h b/builtin/sequencer.h similarity index 100% rename from sequencer.h rename to builtin/sequencer.h -- 1.8.3.698.g079b096 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Move sequencer to builtin
On Sat, Jun 8, 2013 at 5:16 AM, Felipe Contreras felipe.contre...@gmail.com 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 maybe more). Why make an exception for sequencer? What do we gain from this? A lot of code in libgit.a is only used by builtin commands, e.g. fetch-pack.c, should we move it to? I ask because I moved fetch-pack from builtin out because of linking issues and I don't want the same happen to sequencer.c. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
