On Mon, Oct 21, 2024, at 14:08, Patrick Steinhardt wrote: >> […] >> Notes (series): >> From the commit message: >> >> “ The test itself is fine and does not hide a bug: >> `--no-create-reflog` is not supposed to override >> >> A source for that: roundabout through git-branch(1): >> >> “ The negated form --no-create-reflog only overrides an earlier >> --create-reflog, but currently does not negate the setting of >> core.logAllRefUpdates. > > Hm. The "currently" reads as if this was a known shortcoming rather than > by design. I read it as “we might change our minds here—watch out”. ;) It feels very emphasized. Like the documentation was expecting your surprise. >> I *suppose* that the same applies to update-ref since (I suppose) they >> use the same underlying machinery. >> >> See also git-tag(1) which says the same thing. >> >> update-ref should document the same thing, then. I have that marked as >> a todo item. The changes there are a bit too involved to implicate in >> this submission. > > So I'm quite torn here. It's documented, even though the documentation > doesn't exactly feel like this was designed, but rather like it was a > side effect. The test also contradicts the documentation, even though it > only worked by chance. And as mentioned above, everywhere else we > typically have a design where the command line option overrides the > config. > > Overall I'm rather leaning into the direction of making this work > properly. But that would of course be a backwards-incompatible change. Good point. It does feel inconsistent. I agree that the conventional pattern (to my knowledge) is to have options override config when the options are given.
