public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: "Jean-Noël Avila" <jn.avila@free•fr>
To: Junio C Hamano <gitster@pobox•com>
Cc: kristofferhaugsbakk@fastmail•com, git@vger•kernel.org,
	Kristoffer Haugsbakk <code@khaugsbakk•name>
Subject: Re: [PATCH] doc: rerere-options.adoc: link to git-rerere(1)
Date: Thu, 12 Feb 2026 06:37:45 +0100	[thread overview]
Message-ID: <1ce11655-eaef-407f-86af-956a190f5358@free.fr> (raw)
In-Reply-To: <xmqqikc3waju.fsf@gitster.g>

Le 11/02/2026 à 16:43, Junio C Hamano a écrit :
> Jean-Noël Avila <jn.avila@free•fr> writes:
> 
>>> diff --git a/Documentation/rerere-options.adoc b/Documentation/rerere-options.adoc
>>> index b0b920144a6..115882edab1 100644
>>> --- a/Documentation/rerere-options.adoc
>>> +++ b/Documentation/rerere-options.adoc
>>> @@ -4,6 +4,6 @@
>>>  	the current conflict to update the files in the working
>>>  	tree, allow it to also update the index with the result of
>>>  	resolution.  `--no-rerere-autoupdate` is a good way to
>>> -	double-check what `rerere` did and catch potential
>>> +	double-check what linkgit:git-rerere[1] did and catch potential
>>>  	mismerges, before committing the result to the index with a
>>>  	separate `git add`.
>>>
>>> base-commit: 67ad42147a7acc2af6074753ebd03d904476118f
>>
>> I'm not fond of introducing linkgit macro that can create auto-reference
>> in manual pages. At the moment, we need to use conditional inclusion in
>> the manual pages source, but I wonder if we could simply filter out the
>> links in the macro itself.
> 
> FWIW, before deciding to accept the patch, I did check if
> git-rerere.adoc included this file (it didn't), but if we can make
> the macro smarter to do so, it would be great, as that would avoid
> people including this file there later without realizing that they
> now need to make the mark-up conditional.


Ah, adding the options of rerere in git-rerere manual page is then
something that will need to be done when reworking it.


> 
> This particular patch does not have to be blocked waiting for such
> an improvement, though, right?
> 

No it doesn't. I don't intend to scratch this itch soon.

      reply	other threads:[~2026-02-12  5:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-09 18:13 [PATCH] doc: rerere-options.adoc: link to git-rerere(1) kristofferhaugsbakk
2026-02-09 21:57 ` D. Ben Knoble
2026-02-09 22:21   ` Junio C Hamano
2026-02-09 23:12     ` Ben Knoble
2026-02-09 22:23   ` Kristoffer Haugsbakk
2026-02-10 19:56 ` [PATCH v2] " kristofferhaugsbakk
2026-02-10 21:33   ` D. Ben Knoble
2026-02-11  7:14 ` [PATCH] " Jean-Noël Avila
2026-02-11 15:43   ` Junio C Hamano
2026-02-12  5:37     ` Jean-Noël Avila [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=1ce11655-eaef-407f-86af-956a190f5358@free.fr \
    --to=jn.avila@free$(echo .)fr \
    --cc=code@khaugsbakk$(echo .)name \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    --cc=kristofferhaugsbakk@fastmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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