Re: [PATCH] t1400: fix --no-create-reflog test and description
- From
- Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
- Date
- Oct 21, 2024, 16:48 UTC
- Message-ID
- <d66936b8-d12b-4035-b563-328ae9fc4824@app.fastmail.com>
- In-Reply-To
- <ZxZETN7WjbNiSRyF@pks.im>
On Mon, Oct 21, 2024, at 14:08, Patrick Steinhardt wrote:
Show 15 quoted lines
>> […] >> 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.
Show 18 quoted lines
>> 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.