Re: [PATCH 1/3] last-modified: handle and document NUL termination
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Dec 1, 2025, 10:32 UTC
- Message-ID
- <aS1uxbvNE6rAQ1dl@pks.im>
- In-Reply-To
- <87tsye0z61.fsf@iotcl.com>
On Fri, Nov 28, 2025 at 07:50:30PM +0100, Toon Claes wrote:
Show 15 quoted lines
> Junio C Hamano <gitster@pobox.com> writes: > > > Toon Claes <toon@iotcl.com> writes: > > > >> When option `-z` is provided to git-last-modified(1), each line is > >> separated with a NUL instead of a newline. Document this properly and > >> handle parsing of the option in the builtin itself. > > > > I think documenting does make sense, but it is not clear from the > > description why it is better to handle the option in the builtin > > itself, instead of letting the setup_revisions() take care of it. > > I know it's silly, but I wanted to feed these options to > parse_options(). Doing this would make them show up in `git > last-modified -h`.
I think that reasoning makes sense, but it's certainly non-obvious from the commit message. So if you expand the commit message with an explanation the change becomes much more sensible.
Patrick