On Mon, Oct 21, 2024, at 21:02, Taylor Blau wrote: >> […] >> > 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. ;) > 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
