git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Full disclosure

From
Michael Lohmann <mi.al.lohmann@gmail.com>
Date
Jan 17, 2024, 17:41 UTC
Message-ID
<20240117174125.22915-1-mi.al.lohmann@gmail.com>
In-Reply-To
<CAP8UFD3g_N+JJ_cdas2ZdsBPxuQFBXW8yY+1nC6AKvQppOYaDw@mail.gmail.com>
Hi Christian!
Yes: I agree that the current state of the last submitted patch in that
discussion is far from optimal.
After Jeff Kings explanation I had a much better understanding for the
situation and the reasoning (and his suggestion was definitely better than
mine).

I had already prepared a new version which tackled (I think) pretty much all of the criticisms. But then the above mentioned message came in and when I read this:

> [...] they are trying to be different for the sake of being different, which
> is not a good sign.  I'd want our contributors to be original where being
> original matters more.
I am reading:
1) I am "trying to be different for the sake of being different"
2) Contributors like this are not wanted

So yes, I do understand this as a general statement on me as a contributor without any proposal for me at least to explain the situation from my side.

I teach my colleges not to name variables with how they are initialized, but with what information they actually convey and I found the "_NONE" one at least misleading in its name.

So in the initial discussion I was a bit stubborn, because Philip wrote "I don't have a strong opinion" and from my perspective the only argument was "over there we also do it that way" (which _can_ 100% be a valid reason), but Junio C Hamano did not even acknowledge my criticisms of the other the variable name. I am totally fine with a decision like this if done consciously, but if I don't even get an acknowledgement, let alone an explanation, my demands I place on my code quality are that I write the best code I can. And with all the info I had (prior to Jeffs message) I did still favour my first suggestion.

In my eyes it would be helpful to at least tell me what your (in my eyes not obvious) preferences are on naming things, because otherwise I will rather stick to my standards than blindly follow a single instance of other code where I don't even know if that was a concious decision or it just happened by accident.

So no, I don't agree with the assessment of point 1), but I still read the message like that. I will accept it and instead use my skills in different projects where they are indeed valued.

Cheers Michael

Previous: Christian CouderNext: Ruben Safir
Message 12 of 30 in “`log --merge` also for rebase/cherry pick/revert”
  1. `log --merge` also for rebase/cherry pick/revertMichael Lohmann, Jan 11, 2024
  2. Junio C HamanoJan 12, 2024
  3. 1/2 revision: ensure MERGE_HEAD is a ref in prepare_show_mergeMichael Lohmann, Jan 12, 2024
  4. 2/2 revision: Implement `git log --merge` also for rebase/cherry_pick/revertMichael Lohmann, Jan 12, 2024
  5. Junio C HamanoJan 12, 2024
  6. Patrick SteinhardtJan 15, 2024
  7. Junio C HamanoJan 15, 2024
  8. 1/2 revision: ensure MERGE_HEAD is a ref in prepare_show_mergeMichael Lohmann, Jan 17, 2024
  9. 2/2 revision: Implement `git log --merge` also for rebase/cherry_pick/revertMichael Lohmann, Jan 17, 2024
  10. Full disclosureMichael Lohmann, Jan 17, 2024
  11. Christian CouderJan 17, 2024
  12. Full disclosureMichael Lohmann, Jan 17, 2024
  13. Ruben SafirJan 21, 2024
  14. Junio C HamanoJan 17, 2024
  15. Elijah NewrenJan 24, 2024
  16. Junio C HamanoJan 24, 2024
  17. Johannes SixtJan 24, 2024
  18. Junio C HamanoJan 24, 2024
  19. Johannes SixtJan 24, 2024
  20. Junio C HamanoJan 24, 2024
  21. Junio C HamanoFeb 9, 2024
  22. Johannes SixtJan 12, 2024
  23. Johannes SixtJan 12, 2024
  24. Junio C HamanoJan 12, 2024
  25. phillip.wood123@gmail.comJan 12, 2024
  26. Michael LohmannJan 12, 2024
  27. Junio C HamanoJan 12, 2024
  28. Phillip WoodJan 15, 2024
  29. Junio C HamanoJan 12, 2024
  30. Michael LohmannJan 12, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.