four — week 4 #9

Anybody can play. The note is only 20 percent.
The attitude of the motherfucker who plays it is 80 percent.

— Miles Davis

This week is likely to be a bit busy. I’ve got two meetings on Thursday, so I’ll need to free up some time from elsewhere.

I quickly completed the initial migration of ignore_case [1]. This variable is a bit tricky, as I feel its use has been rather lacking in careful consideration in terms of usage. Here is what I said when I send the 'bare' branch (i.e. no commit message no cover letter):

RFC Questions:

environment.h --- Is the fallback logic for repo_get_ignore_case() correct?
I recall that when initialising ignore_case during git init, a string is created
and read to determine the value. Therefore, I am unsure whether gitdir
should be used here, since it might not be ready when we access it.

dir.c --- Performance overhead?

compat/win32/path-utils.c --- Is it appropriate to include the repository.h header file?

Christian suggested taking a look at Patrick’s branch [2] (Actually, I had already looked at it as soon as it was pushed). I was impressed, because he had managed to do something I hadn’t been able to do before on is_bare_repository. The clarity of thinking is astonishing.

Things went relatively smoothly from there. In [3], Junio asked: Why not use repo->initialized consistently, instead of using repo->gitdir specifically for repo->trust_executable_bit?

I remembered that using repo->gitdir previously caused the tests to fail, so I was going to reply to him about that. Fortunately, I ran the tests again and found that the CI failure was actually caused by a minor mistake elsewhere. These patches can indeed uniformly use repo->initialized.

On top of that, Junio emphasized a few points:

• If we need to modify patches that are already in [next], we should create a modification patch based on them, rather than resubmitting the corresponding rebased commit series [4]

• The getters in these three patches are almost identical in nature, so the comments should be merged. The reason we’re not merging them now is that they’re currently in-flight. As mentioned in the previous point, we should wait until they’re merged into [master] before adding the consolidation patch. [5]

• The text in the commits/cover-letters should be self-explanatory. In other words, while it is acceptable to include external links, readers should not be expected to must read them all in order to grasp the key information. As authors, we have an obligation to ensure that the explanation is clear and easy to understand without requiring readers to navigate through various links.

Barring any surprises, the work on these patches is nearly complete; only minor additions will be needed later. I’m happy to be able to take a day off.

Next week, I can either continue working on environment.c (which I’m already quite familiar with) or try something else. We’ll see how it goes!

I’m feeling very, very, very, very down, so this blog post might be full of abusive language (though I hope not). Due to a network fault with Outlook authentication, I haven’t received any emails from the university for the past half month, which meant I missed the deadline to accept my hall of residence offer.
So I’ll be homeless next term.
On top of that, my driving licence training duration review has been rejected.
On top of that, the dog that grew up with me at my sister’s house has died.

[1] malon7782/git#3
[2] https://lore.kernel.org/git/20260611-b4-pks-setup-drop-global-state-v2-6-a6f7269c841d@pks.im/
[3] https://lore.kernel.org/git/xmqqh5n1w0i7.fsf@gitster.g/
[4] https://lore.kernel.org/git/xmqqo6h6jvuk.fsf@gitster.g/
[5] https://lore.kernel.org/git/xmqqjyrujvco.fsf@gitster.g/
[6] https://lore.kernel.org/git/xmqqldcct2hx.fsf@gitster.g/