Re: [PATCH] t1400: fix --no-create-reflog test and description

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Oct 21, 2024, 21:02 UTC
Message-ID: <36959987-5695-48fc-9b4e-2fecfe9f5b88@app.fastmail.com>
In-Reply-To: <ZxalTgct8WhEmO0w@nand.local>

On Mon, Oct 21, 2024, at 21:02, Taylor Blau wrote:

Show 7 quoted lines

>> […]
>> > 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.

Agreed, to be clear. ;)

Show 12 quoted lines

> I agree with you both that it feels inconsistent, but I feel somewhat
> uncomfortable changing the behavior here in a backwards incompatible
> way.
>
> Even if the original documentation leaves the door open to changing the
> behavior, I think that probably a non-zero number of users has either
> (a) never read that documentation, or (b) come to rely on it, or (c)
> both ;-).
>
> I think if anything we might consider updating the documentation to more
> clearly capture the status-quo, but I'd be very hesitant to see a patch
> changing the behavior here.

My background (how I ended up in this test) was that I learnt yesterday that `--create-reflog` and this config variable controls whether reflog files are created. I thought that they toggled when entries were made.

I have some work in progress patches for clarifying this mechanism in git-config(1) and other places.

Now git-tag(1) and git-branch(1) seem decently clear on this point[1] but update-ref is lagging behind IMO. I will be looking at that one as well.

† 1: There is also the `--create-reflog` case vs. when the config is
   `false` but I can’t check that right now