Jeff King wrote: > On Wed, May 10, 2023 at 05:41:57PM -0600, Felipe Contreras wrote: > > Felipe Contreras wrote: > > > Junio C Hamano wrote: > > > > And it led to unproductive and irritating waste of time number of times, and > > > > eventually you were asked to leave the development community for at least a > > > > few times. > > > > > > That is blatantly false. As a member of Git's Project Leadership Committee, you > > > should know precisely how many times the committee has excercised this power, > > > and it hasn't been "a few times", it has been one time. > > > > And for the record: that one time I was asked by the committee to not interact > > with certain members of the community for a few months. > > > > The amount of times I was asked to "leave the development community" is *zero*. > > You're right, in the sense that the first time you were asked to leave > we did not have a CoC, That is is once again: *false*. The git community has *never* asked me to leave. > Likewise, many times during which your behavior has been a problem on the > list, False: it was not a problem on the list, it was a problem *for some people* on the list. > people did not ask you to leave, but simply said "I am not going to read your > messages anymore". Yes, and for every person who has said "I am not going to read your messages" publicly, I received a response saying "thank you for saying what we are all thinking but cannot say aloud for fear of reprisals" privately. You do understand that people have different opinions? Some people hate Donald Trump, some people don't. And some people cannot express their honest opinion at $dayjob. Having a different opinion is OK. And the foundation of a functioning civilized democracy is to tolerate the opinions of others. > For example, here's Junio asking you to leave in 2013: > > https://lore.kernel.org/git/7vsj0lvs8f.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ Read the thread. My objective was to show that the code organization was wrong, and libgit.a was not an actual library. If there ever was any hope of having an actual libgit library, the code needed to be reorganized: ==== The plan is simple; make libgit.a a proper library, starting by clarifying what goes into libgit.a, and what doesn't. If there's any hopes of ever having a public library, it's clear what code doesn't belong in libgit.a; code that is meant for builtins, that code belongs in builtins/lib.a, or similar. ==== Felipe Contreras: [1] The whole libification project of Google proves I was right: git was not (and is not) ready to be a library. libgit.a is not nearly close to be an actual standalone library. Pretty far from it. Just today Elijah Newren sent a 27-patch series [2] attempting to move in the right direction, but doesn't even begin to tip the scales to make libgit.so possible. My proposal did receive positive feedback: ==== Nice joke patch to illustrate your point ;) ==== Ramkumar Ramachandra: [3] ==== This is a good example: yes, I'm convinced that the code does need to be reorganized. ==== Ramkumar Ramachandra: [4] Even you yourself provided useful positive feedback based on my proposal: ==== If we want to start caring, then we probably need to create a separate "kitchen sink"-like library, with the rule that things in libgit.a cannot depend on it. In other words, a support library for Git's commands, for the parts that are not appropriate to expose as part of a library API. ==== Jeff King: [5] Junio also provided good feedback initially: ==== Another thing to think about is looking at pieces of data and functions defined in each *.o files and moving things around within them. For example, looking at the dependency chain I quoted earlier for sequencer.o to build upload-pack, which is about responding to "git fetch" on the sending side: ... It is already crazy. There is no reason for the pack sender to be linking with the sequencer interpreter machinery. If the function definition (and possibly other ones) are split into separate source files (still in libgit.a), git-upload-pack binary does not have to pull in the whole sequencer.c at all. ==== Junio C Hamano: [6] Things started to turn south when I expressed the following opinion: ==== But init_copy_notes_for_rewrite() can *not* be used by anything other than git builtins. Standalone binaries will never use such a function, therefore it doesn't belong in libgit.a. Another example is alias_lookup(). They belong in builtin/lib.a. ==== Felipe Contreras: [7] Junio asked me for an example of a function that would not belong to libgit.so, and I said `init_copy_notes_for_rewrite()` is an example of a function that nothing outside the `git` binary would need. ==== But that is not a good justification for closing door to others that come later who may want to have a standalone that would want to use it. Think about rewriting filter-branch.sh in C but not as a built-in, for example. ==== Junio C Hamano: [8] I argued nobody would actually do that, and I was right, as eventually filter-branch.sh was rewritten in C, but as a builtin, as I said it would. Junio then argued that there was no justification for my claim that certain functions would only be used by git builtins, and therefore they should not belong in a libgit.so library: ==== >> You still haven't justified why we have to _forbid_ any outside >> callers from calling copy_notes_for_rewrite(). > > Because only builtins _should_ use it. And there is no justification behind that "_should_" claim; you are not making any technical argument to explain it. ==== Junio C Hamano: [9] Google's libification project proves I was right: some functions should not belong in libgit.a. If Junio had listened to me back in 2013, the changes Google developers are working on now to make libgit.a something that remotely resembles an actual library would not be as monumental as they are in 2023. Instead of considering my argument, Junio chose to attack me personally: ==== I do not see a point in continuing to discuss this (or any design level issues) with you. You seem to go into a wrong direction to break the design of the overall system, not in a direction to improve anything. I do not know, and at this point I do not care, if you are doing so deliberately to sabotage Git. Just stop. ==== Junio C Hamano: [9] Even if Junio's opinion was the correct one (it's not: as Google's libification project proves), it's not OK to personally attack a contributor merely for expressing an opinion that happens to differ from that of the maintainer. I am entitled to have my own opinion. I already know what you are going to argue back: you are going to argue that Google's libification project is different from my argument, but it's not: Emily Shaffer's introductory mail explained the same thing: ==== In other words, for some modules which already have clear boundaries inside of Git - like config.[ch], strbuf.[ch], etc. - we want to remove some implicit dependencies, like references to globals, and make explicit other dependencies, like references to other modules within Git. ==== Emily Shaffer: [10] Google developers clearly believe the boundaries between "modules" are not clear, and they should be. Which is *exactly* what I argued back in 2013. You say Junio asked me to leave, but you conveniently avoid explaining *why*: because he didn't like my opinion. Junio was not content with simply saying "let's agree to disagree", he threw yet another personal attack: ==== So I do not think this is not even a bikeshedding. Just one side being right, and the other side continuing to repeat nonsense without listening. ==== Junio C Hamano: [11] And then: ==== But what followed was a nonsense, which ended up wastign everybody's time: ==== Junio C Hamano: [12] This breaks the current code of conduct, as it clearly is a behavior that is not: * Demonstrating empathy and kindness toward other people * Being respectful of differing opinions, viewpoints, and experiences This is what I objectively did *not* do in that thread: * Denigrate the opinions of others * Personally attack anybody It was Junio the one who did that, not me. Junio asked me to leave because I expressed an *opinion* he did not like. Junio asked me to leave because I said in my opinion `copy_notes_for_rewrite()` does not belong in libgit.a, because only git builtins should use it. That's it. I think it's incredibly deceitful of you to claim "Junio asked you to leave" and provide a link, without explaining *why*. Fast-forward to 2023, and Google developers are using the same language as I did in 2013: ==== Strbuf is a widely used basic structure that should only interact with other primitives in strbuf.[ch]. ==== Calvin Wan: [13] Is Junio asking them to leave the project for merely daring to express an opinion about what *should* be the direction the Git project takes? Of course not. Ironically, the link you shared is a perfect example the double standards of the Git project, in which a normative statement from a Google employee is par for the course, but a normative statement from an unaffiliated contributor (i.e. me) is complete heresy. All of this is of course, nothing more than a smoke screen from the topic at hand. --- This is the topic: Subject: Re: [PATCH v2] diff: fix interaction between the "-s" option and other options All that matters here is this: 1. Apply Junio's patch 2. Run this command `git diff -s --raw @~` Does the command produce the same output before and after the patch? Yes or no. That is it. Stop dragging personal drama between Junio and me from 2013 in which nobody else participated--including you--and answer the *only* relevant question in this thread. Does Junio's patch change the current behavior? a. Yes b. No Cheers. [1] https://lore.kernel.org/git/CAMP44s0cozMsTo7KQAjnqkqmvMwMw9D3SZrVxg48MOXkH9UQJQ@xxxxxxxxxxxxxx/ [2] https://lore.kernel.org/git/pull.1525.v2.git.1683875068.gitgitgadget@xxxxxxxxx/ [3] https://lore.kernel.org/git/CALkWK0mA7MXQv1k5bFpZLARDOHxU5kzKFXzcyUfb6NLZZY-=FA@xxxxxxxxxxxxxx/ [4] https://lore.kernel.org/git/CALkWK0=7PRndNc7XQ-PCPbVCp9vck909bA561JhQG6uXXj1n4g@xxxxxxxxxxxxxx/ [5] https://lore.kernel.org/git/20130610220627.GB28345@xxxxxxxxxxxxxxxxxxxxx/ [6] https://lore.kernel.org/git/7vwqq1ct0g.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ [7] https://lore.kernel.org/git/CAMP44s03iXPVnunBdFT8etvZ-ew-D15A7mCV3wAAFXMNCpRAgA@xxxxxxxxxxxxxx/ [8] https://lore.kernel.org/git/7vppvsbkc3.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ [9] https://lore.kernel.org/git/7vobbca1sr.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ [10] https://lore.kernel.org/git/CAJoAoZ=Cig_kLocxKGax31sU7Xe4==BGzC__Bg2_pr7krNq6MA@xxxxxxxxxxxxxx/ [11] https://lore.kernel.org/git/7vehc8a05n.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ [12] https://lore.kernel.org/git/7vzjuv14ir.fsf@xxxxxxxxxxxxxxxxxxxxxxxx/ [13] https://lore.kernel.org/git/20230503184849.1809304-1-calvinwan@xxxxxxxxxx/ -- Felipe Contreras
