Re: [PATCH v2] diff: fix interaction between the "-s" option and other options

Jeff King wrote:

That is is once again: *false*.

The git community has *never* asked me to leave.

False: it was not a problem on the list, it was a problem *for some people* on
the list.

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.

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@mail.gmail.com/ [2] https://lore.kernel.org/git/pull.1525.v2.git.1683875068.gitgitgadget@gmail.com/ [3] https://lore.kernel.org/git/CALkWK0mA7MXQv1k5bFpZLARDOHxU5kzKFXzcyUfb6NLZZY-=FA@mail.gmail.com/ [4] https://lore.kernel.org/git/CALkWK0=7PRndNc7XQ-PCPbVCp9vck909bA561JhQG6uXXj1n4g@mail.gmail.com/ [5] https://lore.kernel.org/git/20130610220627.GB28345@sigill.intra.peff.net/ [6] https://lore.kernel.org/git/7vwqq1ct0g.fsf@alter.siamese.dyndns.org/ [7] https://lore.kernel.org/git/CAMP44s03iXPVnunBdFT8etvZ-ew-D15A7mCV3wAAFXMNCpRAgA@mail.gmail.com/ [8] https://lore.kernel.org/git/7vppvsbkc3.fsf@alter.siamese.dyndns.org/ [9] https://lore.kernel.org/git/7vobbca1sr.fsf@alter.siamese.dyndns.org/ [10] https://lore.kernel.org/git/CAJoAoZ=Cig_kLocxKGax31sU7Xe4==BGzC__Bg2_pr7krNq6MA@mail.gmail.com/ [11] https://lore.kernel.org/git/7vehc8a05n.fsf@alter.siamese.dyndns.org/ [12] https://lore.kernel.org/git/7vzjuv14ir.fsf@alter.siamese.dyndns.org/ [13] https://lore.kernel.org/git/20230503184849.1809304-1-calvinwan@google.com/