From: "Étienne Servais" <etienne.servais@voucoux.fr>
To: git@vger.kernel.org
Cc: Jeff King <peff@peff.net>
Subject: Re: [PATCH] doc: add documentation for git log --no-follow
Date: Mon, 3 Feb 2020 21:27:46 +0100 [thread overview]
Message-ID: <8d0dbaa2-938e-1797-98d7-3f9abeb5b863@voucoux.fr> (raw)
In-Reply-To: <20200201111636.GC1864948@coredump.intra.peff.net>
Le 01/02/2020 à 12:16, Jeff King a écrit :
> On Sat, Feb 01, 2020 at 12:24:31AM +0100, Étienne Servais wrote:
>
>> This feature was added by commit
>> 076c98372e (log: add "log.follow" configuration variable, 2015-07-07)
>> but remained undocumented.
>
> That commit just touched the code; it was originally added by aebbcf5797
> (diff: accept --no-follow option, 2012-09-21). But I think the general
> intent of your patch is still valid.
Good catch. Corrected in upcoming patch v2
>> I couldn't figure if I shall merge the --no-follow doc with the follow
>> as is done for --no-decorate and --decorate just after.
>
> I think it would make more sense to just put it with --follow, like:
>
> [--no-]follow::
>
> which matches how --use-mailmap is defined, for instance.
Ok, I've turned it to (inspired by the --[no-]rename-empty doc)
---follow::
- Continue listing the history of a file beyond renames
+--[no-]follow::
+ Whether to continue listing the history of a file beyond renames
(works only for a single file).
>
>> @@ -205,7 +208,8 @@ log.follow::
>> 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 setting can be disabled by the `--no-follow`
>> + option.
>
> I'm on the fence on this hunk. There are a number of config options that
> can be canceled or overridden by command-line options. It's a normal
> pattern for the "--no" variant to do so. So while it often doesn't hurt
> to give a pointer in the right direction, I don't know that we'd want to
> start doing so in every such case.
OK. I had just borrowed that sentence from notes.displayRef few lines below.
Some config options doc follow this direction like log.abbrevCommit or log.mailmap.
I'll follow you on this.
--
Étienne Servais
next prev parent reply other threads:[~2020-02-03 20:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-31 23:24 [PATCH] doc: add documentation for git log --no-follow Étienne Servais
2020-02-01 11:16 ` Jeff King
2020-02-03 20:27 ` Étienne Servais [this message]
2020-02-03 14:40 ` [PATCH] index-pack: downgrade twice-resolved REF_DELTA to die() Jeff King
2020-02-03 17:53 ` Taylor Blau
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=8d0dbaa2-938e-1797-98d7-3f9abeb5b863@voucoux.fr \
--to=etienne.servais@voucoux.fr \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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;
as well as URLs for NNTP newsgroup(s).