Dear Junio, Thank you for the feedback, I adjusted the commit message in full which hopefully makes this patch clearer. At the same time I don't quite understand the need for the perceived hostility - this is not some "fuzzy" words, but the messaging from the original author of the sparse feature. I certainly understand your desire to uphold the standards of contributions to git, especially from the new author, but I must say I feel quite alienated by your reply. Nonetheless, the adjustment is submitted now and I hope that further contributions remain welcomed. On Wed, May 21, 2025 at 11:23 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Alex Mironov <alexandrfox@xxxxxxxxx> writes: > > > >> Hey Junio, > >> > >> With respect to messaging I more or less copy-pasted Derricks message > >> from the original commit for non-threaded init: please check the > >> referenced commit. Let me know if another wording is needed/preferred. > > > > I know what you did. Copying and pasting others fuzzy words into > > your commit log message does not make your commit log message clear. > > > > I already said the given message is less clear than desired, so do I > > still have to let you know??? > > Actually after re-reading what Derrick wrote in that commit, I > notice that you didn't even copy-pasted his message in full. Here > is the message in 5f116695 (name-hash: don't add directories to > name_hash, 2021-04-12): > > name-hash: don't add directories to name_hash > > Sparse directory entries represent a directory that is outside the > sparse-checkout definition. These are not paths to blobs, so should not > be added to the name_hash table. Instead, they should be added to the > directory hashtable when 'ignore_case' is true. > > Add a condition to avoid placing sparse directories into the name_hash > hashtable. This avoids filling the table with extra entries that will > never be queried. > > Notice that the second paragraph here makes it clear that how extra > entries would not contribute to or hurt the correctness? You failed > to copy-paste that crucial bit, which ended up making your version > of the explanation much less clear why the change would not affect > correctness than it could have been. -- Best, Alex Mironov