From: Kristoffer Haugsbakk Date: Fri, 13 Jun 2025 09:52:01 GMT Subject: Re: [PATCH RFC v2 1/5] last-modified: new subcommand to show when files were last modified 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: > Patrick Steinhardt 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