Re: [PATCH RFC v2 1/5] last-modified: new subcommand to show when files were last modified

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Jun 13, 2025, 09:52 UTC
Message-ID: <12b49804-946e-4bfe-a1ce-e7f712363076@app.fastmail.com>
In-Reply-To: <87ldpw0yu3.fsf@iotcl.com>

On Fri, Jun 13, 2025, at 11:34, Toon Claes wrote:

Show 24 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
>
>> On Fri, May 23, 2025 at 11:33:48AM +0200, Toon Claes wrote:
>>> diff --git a/Documentation/git-last-modified.adoc b/Documentation/git-last-modified.adoc
>>> new file mode 100644
>>> index 0000000000..1af38f402e
>>> --- /dev/null
>>> +++ b/Documentation/git-last-modified.adoc
>>> @@ -0,0 +1,49 @@
>>> +git-last-modified(1)
>>> +====================
>>> +
>>> +NAME
>>> +----
>>> +git-last-modified - EXPERIMENTAL: Show when files were last modified
>>
>> Nit: we don't have the EXPERIMENTAL label here for git-switch(1) or
>> git-restore(1).
>
> But we do for `git-replay(1)`. Because I haven't gotten much feedback
> about the usage of the command, I wanted to be on the safe side and not
> commit to the behavior. Marking it EXPERIMENTAL would allow us to make
> changes on it's interface without _breaking_. But I wouldn't mind
> dropping the experimental status.

As a user I appreciate that experimental commands are prominently called out as such, like it is here. I don’t see much user testing (more as in DX/developer experience) on the mailing list for new commands.[1] “Experimental” in my interpretation means that I should be careful about using it in scripts and that the developers are open to making changes to the command interface.

† 1: I mean specifically by a slightly wider user base; those of us who
    might not be able to hack on or review the relevant code much but might
    be interested in what the command interface will be like.

Thanks

-- 
Kristoffer Haugsbakk