git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Lohmann <mi.al.lohmann@gmail.com>
To: christian.couder@gmail.com
Cc: git@vger.kernel.org, gitster@pobox.com, j6t@kdbg.org,
	mi.al.lohmann@gmail.com, newren@gmail.com,
	phillip.wood123@gmail.com
Subject: Full disclosure
Date: Wed, 17 Jan 2024 18:41:24 +0100	[thread overview]
Message-ID: <20240117174125.22915-1-mi.al.lohmann@gmail.com> (raw)
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

  reply	other threads:[~2024-01-17 17:41 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 23:33 [RFC PATCH] `log --merge` also for rebase/cherry pick/revert Michael Lohmann
2024-01-12  0:15 ` Junio C Hamano
2024-01-12 15:50   ` [PATCH v2 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Michael Lohmann
2024-01-12 15:50     ` [PATCH v2 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert Michael Lohmann
2024-01-12 20:10     ` [PATCH v2 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Junio C Hamano
2024-01-15 11:36       ` Patrick Steinhardt
2024-01-15 17:19         ` Junio C Hamano
2024-01-17  8:14       ` [PATCH v3 " Michael Lohmann
2024-01-17  8:14         ` [PATCH v3 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert Michael Lohmann
2024-01-17  9:19           ` Full disclosure Michael Lohmann
2024-01-17  9:58             ` Christian Couder
2024-01-17 17:41               ` Michael Lohmann [this message]
2024-01-21  0:41                 ` Ruben Safir
2024-01-17 18:33             ` Junio C Hamano
2024-01-24  7:06           ` [PATCH v3 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert Elijah Newren
2024-01-24 17:19             ` Johannes Sixt
2024-01-24 19:46               ` Junio C Hamano
2024-01-24 22:06                 ` Johannes Sixt
2024-01-24 22:13                   ` Junio C Hamano
2024-02-09 23:54               ` Junio C Hamano
2024-01-24 17:34             ` Junio C Hamano
2024-02-10 23:35         ` [PATCH v4 0/2] Implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-10 23:35           ` [PATCH v4 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Philippe Blain
2024-02-10 23:35           ` [PATCH v4 2/2] revision: implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-11  8:34             ` Johannes Sixt
2024-02-11 16:43               ` Philippe Blain
2024-02-11 17:59                 ` Johannes Sixt
2024-02-12 18:27                   ` Junio C Hamano
2024-02-12 11:02             ` Phillip Wood
2024-02-13 13:27               ` Philippe Blain
2024-02-14 11:02                 ` Phillip Wood
2024-02-13  8:33             ` Jean-Noël Avila
2024-02-13 13:14               ` Philippe Blain
2024-02-25 21:56           ` [PATCH v5 0/2] Implement " Philippe Blain
2024-02-25 21:56             ` [PATCH v5 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Philippe Blain
2024-02-26 17:22               ` Jean-Noël Avila
2024-02-26 17:54                 ` Philippe Blain
2024-02-25 21:56             ` [PATCH v5 2/2] revision: implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-26  4:35               ` Junio C Hamano
2024-02-26 17:43                 ` Philippe Blain
2024-02-27 14:00             ` [PATCH v5 0/2] Implement " Phillip Wood
2024-02-27 18:30               ` Junio C Hamano
2024-02-28 13:54             ` [PATCH v6 " Philippe Blain
2024-02-28 13:54               ` [PATCH v6 1/2] revision: ensure MERGE_HEAD is a ref in prepare_show_merge Philippe Blain
2024-02-28 13:54               ` [PATCH v6 2/2] revision: implement `git log --merge` also for rebase/cherry-pick/revert Philippe Blain
2024-02-28 14:40               ` [PATCH v6 0/2] Implement " phillip.wood123
2024-03-02 15:35                 ` Philippe Blain
2024-01-12  7:35 ` [RFC PATCH] `log --merge` also for rebase/cherry pick/revert Johannes Sixt
2024-01-12  7:59   ` Johannes Sixt
2024-01-12 20:18   ` Junio C Hamano
2024-01-12 11:01 ` phillip.wood123
2024-01-12 15:03   ` Michael Lohmann
2024-01-12 21:14     ` Junio C Hamano
2024-01-15 10:48     ` Phillip Wood
2024-01-12 20:21   ` Junio C Hamano
2024-01-12 21:06     ` Michael Lohmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240117174125.22915-1-mi.al.lohmann@gmail.com \
    --to=mi.al.lohmann@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=newren@gmail.com \
    --cc=phillip.wood123@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).