public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Toon Claes <toon@iotcl.com>
To: Karthik Nayak <karthik.188@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH 2/3] last-modified: document option --max-depth
Date: Fri, 16 Jan 2026 13:13:49 +0100	[thread overview]
Message-ID: <87fr85kb5u.fsf@iotcl.com> (raw)
In-Reply-To: <CAOLa=ZSbV6SeJ9orOz0T+oh3PVhYhTsaxrsYVkr+5q7i_tsVCw@mail.gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

> Toon Claes <toon@iotcl.com> writes:
>
>> Option --max-depth is supported by git-last-modified(1), because it was
>> added to the diff machinery in a1dfa5448d (diff: teach tree-diff a
>> max-depth parameter, 2025-08-07).
>>
>
> At this point, does it make more sense to link the respective sections
> within 'Documentation/diff-options.adoc' as done by many other commands?
> This would ensure that we don't have to repeat the documentation.

Nah, there are way too many options that are not relevant for this
command in there. I agree, it's annoying to duplicate things. But I
don't know there's an easy way around that right now.

>> This option is useful for everyday use of the git-last-modified(1)
>> command, so document it's existence in the man page and `-h` output.
>>
>> Signed-off-by: Toon Claes <toon@iotcl.com>
>> ---
>>  Documentation/git-last-modified.adoc |  9 ++++++++-
>>  builtin/last-modified.c              | 12 +++++++++++-
>>  2 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/git-last-modified.adoc b/Documentation/git-last-modified.adoc
>> index cd4a5040b0..8409daebe9 100644
>> --- a/Documentation/git-last-modified.adoc
>> +++ b/Documentation/git-last-modified.adoc
>> @@ -9,7 +9,8 @@ git-last-modified - EXPERIMENTAL: Show when files were last modified
>>  SYNOPSIS
>>  --------
>>  [synopsis]
>> -git last-modified [--recursive] [--show-trees] [-z] [<revision-range>] [[--] <path>...]
>> +git last-modified [--recursive] [--show-trees] [--max-depth=<depth>] [-z]
>> +	[<revision-range>] [[--] <path>...]
>>
>>  DESCRIPTION
>>  -----------
>> @@ -32,6 +33,12 @@ OPTIONS
>>  	Show tree entries even when recursing into them. It has no effect
>>  	without `--recursive`.
>>
>> +`--max-depth=<depth>`::
>> +	For each pathspec given on the command line, descend at most `<depth>`
>> +	levels of directories. A negative value means no limit.
>> +	Setting a positive value implies `--recursive`.
>> +	Cannot be combined with wildcards in the pathspec.
>> +
>>  `-z`::
>>  	Terminate each line with a _NUL_ rather than a newline.
>>
>> diff --git a/builtin/last-modified.c b/builtin/last-modified.c
>> index 9206bbdc1d..ccb7ff66d4 100644
>> --- a/builtin/last-modified.c
>> +++ b/builtin/last-modified.c
>> @@ -25,6 +25,7 @@
>>
>>  #define LAST_MODIFIED_INIT { \
>>  	.line_termination = '\n', \
>> +	.max_depth = -1, \
>>  }
>>
>>  struct last_modified_entry {
>> @@ -60,6 +61,7 @@ struct last_modified {
>>  	bool recursive;
>>  	bool show_trees;
>>  	int line_termination;
>> +	int max_depth;
>>
>
> Should this be signed?

Yes, a negative number is allowed to set an unlimited max depth.

>
>>  	const char **all_paths;
>>  	size_t all_paths_nr;
>> @@ -487,6 +489,12 @@ static int last_modified_init(struct last_modified *lm, struct repository *r,
>>  	lm->rev.diffopt.flags.recursive = lm->recursive;
>>  	lm->rev.diffopt.flags.tree_in_recursive = lm->show_trees;
>>
>> +	if (lm->max_depth >= 0) {
>> +		lm->rev.diffopt.flags.recursive = 1;
>> +		lm->rev.diffopt.max_depth = lm->max_depth;
>> +		lm->rev.diffopt.max_depth_valid = 1;
>> +	}
>> +
>
> Or if our goal is to actually handle them within the
> 'git-last-modified(1)' command, shouldn't we ensure we don't allow any
> additional flags from being parsed as diffopt?

Is that possible?

All the magic that happens in setup_revision() is a little bit of a pain
if you ask me. 

> Currently other diffopts flags such as '--no-prefix', '--cc' and so on,
> are parsed even if they don't affect the output of
> 'git-last-modified(1)'. Shouldn't we disallow such behavior?

I think this would require a revamp of setup_revision(). But I'm happy
to be proven otherwise.

>>  	argc = setup_revisions(argc, argv, &lm->rev, NULL);
>>  	if (argc > 1) {
>>  		error(_("unknown last-modified argument: %s"), argv[1]);
>> @@ -515,7 +523,7 @@ int cmd_last_modified(int argc, const char **argv, const char *prefix,
>>  	struct last_modified lm = LAST_MODIFIED_INIT;
>>
>>  	const char * const last_modified_usage[] = {
>> -		N_("git last-modified [--recursive] [--show-trees] [-z] "
>> +		N_("git last-modified [--recursive] [--show-trees] [--max-depth=<depth>] [-z] "
>>  		   "[<revision-range>] [[--] <path>...]"),
>>  		NULL
>>  	};
>> @@ -525,6 +533,8 @@ int cmd_last_modified(int argc, const char **argv, const char *prefix,
>>  			 N_("recurse into subtrees")),
>>  		OPT_BOOL('t', "show-trees", &lm.show_trees,
>>  			 N_("show tree entries when recursing into subtrees")),
>> +		OPT_INTEGER_F(0, "max-depth", &lm.max_depth,
>> +			N_("maximum tree depth to recurse"), PARSE_OPT_NONEG),
>>  		OPT_SET_INT('z', NULL, &lm.line_termination,
>>  			N_("lines are separated with NUL character"), '\0'),
>>  		OPT_END()
>>
>> --
>> 2.51.2

-- 
Cheers,
Toon

  reply	other threads:[~2026-01-16 12:14 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-26  6:09 [PATCH 0/3] Expand and enhance git-last-modified(1) documentation Toon Claes
2025-11-26  6:09 ` [PATCH 1/3] last-modified: handle and document NUL termination Toon Claes
2025-11-26 13:03   ` Karthik Nayak
2025-11-26 16:57   ` Junio C Hamano
2025-11-28 18:50     ` Toon Claes
2025-12-01 10:32       ` Patrick Steinhardt
2025-11-26  6:09 ` [PATCH 2/3] last-modified: document option --max-depth Toon Claes
2025-11-26 13:31   ` Karthik Nayak
2026-01-16 12:13     ` Toon Claes [this message]
2025-11-26 19:49   ` Junio C Hamano
2025-11-28 18:51     ` Toon Claes
2025-11-26  6:09 ` [PATCH 3/3] last-modified: better document how depth in handled Toon Claes
2025-11-26 17:38   ` Eric Sunshine
2025-12-01 10:32   ` Patrick Steinhardt
2025-12-02 11:01     ` Toon Claes
2025-12-02 17:14       ` Patrick Steinhardt
2026-01-16 13:22 ` [PATCH v2 0/5] Change git-last-modified(1) default behavior and add documentation Toon Claes
2026-01-16 13:22   ` [PATCH v2 1/5] last-modified: document NUL termination Toon Claes
2026-01-16 13:22   ` [PATCH v2 2/5] last-modified: add option '-z' to help output Toon Claes
2026-01-16 18:31     ` Junio C Hamano
2026-01-16 13:22   ` [PATCH v2 3/5] last-modified: document option --max-depth Toon Claes
2026-01-16 13:22   ` [PATCH v2 4/5] last-modified: add option '--max-depth' to help output Toon Claes
2026-01-16 18:42     ` Junio C Hamano
2026-01-16 13:22   ` [PATCH v2 5/5] last-modified: change default max-depth to 0 Toon Claes
2026-01-16 18:55     ` Junio C Hamano
2026-01-16 13:34   ` [PATCH v2 0/5] Change git-last-modified(1) default behavior and add documentation Kristoffer Haugsbakk
2026-01-20 10:44     ` Toon Claes
2026-01-20 21:47   ` [PATCH v3 0/4] " Toon Claes
2026-01-20 21:47     ` [PATCH v3 1/4] last-modified: clarify in the docs the command takes a pathspec Toon Claes
2026-01-20 21:47     ` [PATCH v3 2/4] last-modified: document option '-z' Toon Claes
2026-01-20 21:47     ` [PATCH v3 3/4] last-modified: document option '--max-depth' Toon Claes
2026-01-20 21:47     ` [PATCH v3 4/4] last-modified: change default max-depth to 0 Toon Claes
2026-01-25 11:24       ` Kristoffer Haugsbakk
2026-01-21 18:40     ` [PATCH v3 0/4] Change git-last-modified(1) default behavior and add documentation Junio C Hamano
2026-02-03  9:58       ` Karthik Nayak
2026-02-03 17:42         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fr85kb5u.fsf@iotcl.com \
    --to=toon@iotcl.com \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox