From: Junio C Hamano <gitster@pobox.com>
To: Tamir Duberstein <tamird@gmail.com>
Cc: git@vger.kernel.org, "Jean-Noël Avila" <jn.avila@free.fr>,
"Miklos Vajna" <vmiklos@collabora.com>
Subject: Re: [PATCH v4] doc: clarify --follow and log.follow for git log
Date: Thu, 25 Jun 2026 10:23:52 -0700 [thread overview]
Message-ID: <xmqqpl1efs9j.fsf@gitster.g> (raw)
In-Reply-To: <20260625-document-log-no-follow-v4-1-9bb233248b8f@gmail.com> (Tamir Duberstein's message of "Thu, 25 Jun 2026 12:01:18 -0400")
Tamir Duberstein <tamird@gmail.com> writes:
> aebbcf5797 (diff: accept --no-follow option, 2012-09-21) added the
> --no-follow option, but git-log(1) only documents --follow.
>
> Document --no-follow alongside --follow, and note that it overrides
> the log.follow configuration.
>
> Signed-off-by: Tamir Duberstein <tamird@gmail.com>
> ---
> Changes in v4:
> - Limit the patch to `--no-follow` and its `log.follow` override; leave
> the existing `--follow` limitations unchanged.
> - Link to v3: https://patch.msgid.link/20260510-document-log-no-follow-v3-1-d6d3368c64bb@gmail.com
OK.
> Changes in v3:
> - List `--no-follow` before `--follow`.
Ah, I think I misread the patch and its preimage while reviewing v2
and I didn't notice my mistake when you sent v3. Sorry.
I somehow thought that the original before the patch was
--follow::
... description of follow here ...
--no-follow::
... description of no-follow here ..
and I thought the patch was doing
--follow::
--no-follow::
... combined description ...
and commented that it was a good change. I didn't mean to comment
which between --no-foo and --foo should come first (looking at the
output of "git grep -C1 -E -e '^`?--no-'", I think --foo should come
before --no-foo, especially when --foo does not take any value, but
it seems there are many instances that list the negated form first).
As the existing text has mixture of --foo before and after --no-foo
let's not worry about which one should come first, but if we have a
chance to redo this patch, I would actually prefer to see --follow
comes before --no-follow.
> diff --git a/Documentation/config/log.adoc b/Documentation/config/log.adoc
> index f20cc25cd7..58147dff9b 100644
> --- a/Documentation/config/log.adoc
> +++ b/Documentation/config/log.adoc
> @@ -54,7 +54,7 @@ This is the same as the `--decorate` option of the `git log`.
> If `true`, `git log` will act as if the `--follow` option was used when
> a single <path> is given. This has the same limitations as `--follow`,
> i.e. it cannot be used to follow multiple files and does not work well
> - on non-linear history.
> + on non-linear history. This can be overridden by `--no-follow`.
OK. This is the usual "command line options override configured
default" in play.
> diff --git a/Documentation/git-log.adoc b/Documentation/git-log.adoc
> index fb3ac11283..64fbec0f57 100644
> --- a/Documentation/git-log.adoc
> +++ b/Documentation/git-log.adoc
> @@ -27,9 +27,12 @@ each commit introduces are shown.
> OPTIONS
> -------
>
> +`--no-follow`::
> `--follow`::
> Continue listing the history of a file beyond renames
> - (works only for a single file).
> + (works only for a single file). `--no-follow` disables this
> + behavior, including when it was enabled by the
> + `log.follow` configuration variable.
Ditto, but I am not sure if we want to sprinkle the "command line
overrides configured defaults" all over the place. The description
of --[no-]decorate below says
default to configuration value of `log.decorate` if
configured, otherwise `auto`.
which silently assumes that the readers _know_ that command line
--no-decorate overrides that default. And I think it is a sensible
assumption to make.
So, while the patch may have meant well, I think this part should
actually become a single liner that adds `--no-follow`:: and nothing
else. The changes to config/log.adoc should probably be kept.
Thanks.
prev parent reply other threads:[~2026-06-25 17:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-07 14:14 [PATCH] doc: git-log: document --no-follow Tamir Duberstein
2026-05-07 18:13 ` [PATCH v2] doc: git-log: clarify --follow options Tamir Duberstein
2026-05-10 21:31 ` Junio C Hamano
2026-05-10 22:30 ` Tamir Duberstein
2026-05-10 23:48 ` Junio C Hamano
2026-05-10 23:51 ` Tamir Duberstein
2026-05-10 22:31 ` [PATCH v3] doc: clarify --follow and log.follow for git log Tamir Duberstein
2026-05-10 23:53 ` Junio C Hamano
2026-05-11 0:07 ` Tamir Duberstein
2026-05-11 0:13 ` Junio C Hamano
2026-05-11 0:32 ` Tamir Duberstein
2026-05-11 0:46 ` Junio C Hamano
2026-05-11 1:28 ` Tamir Duberstein
2026-05-11 2:06 ` Junio C Hamano
2026-06-25 16:01 ` [PATCH v4] " Tamir Duberstein
2026-06-25 17:23 ` Junio C Hamano [this message]
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=xmqqpl1efs9j.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jn.avila@free.fr \
--cc=tamird@gmail.com \
--cc=vmiklos@collabora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.