From: Patrick Steinhardt <ps@pks.im>
To: kristofferhaugsbakk@fastmail.com
Cc: git@vger.kernel.org, Kristoffer Haugsbakk <code@khaugsbakk.name>
Subject: Re: [RFC PATCH 1/4] doc: transform breaking changes doc to a manpage
Date: Wed, 30 Sep 2026 15:28:41 +0200 [thread overview]
Message-ID: <ar0OicAaDipYx-xU@pks.im> (raw)
In-Reply-To: <gitbrchanges7_please.d1d@m5gid.xyz>
On Mon, Sep 28, 2026 at 12:41:25PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> The breaking changes document is not a regular Git documentation page.
> That means that you cannot navigate to the doc with git(1), i.e. with:
>
> git help BreakingChanges
>
> You instead have to download the Git project source. Or go to
> git-scm.com.[1] Then you get this disclaimer:[2]
>
> This information is specific to the Git project
>
> Please note that this information is only relevant to you if you
> plan on contributing to the Git project itself. It is in no shape or
> form required reading for regular Git users.
>
> But this document is relevant to *all* Git users. Everyone should have
> as easy access to it as the other doc and guide pages.
Yeah, I agree with that sentiment. The one interesting question about it
is of course what we'll do with the document once Git 3.0 is out. Will
we retain it? Will we remove it? Will we empty it and make it focus on
Git 4.0?
I guess once it's a manpage we should definitely retain its contents for
a while longer. The breaking changes will be relevant to users even
after they've already upgraded to Git 3.0. But if so, we should probably
introduce a new section for Git 4.0, at least if we already want to
start thinking about that.
NB: even if we start thinking about it I think we should probably not
release it anytime soon. I guess having a major release once per
decade may be good enough.
> To that end, let’s move the text to a manpage. But keep the old page,
> just linking to the new one. (We wouldn’t want to break any readers.)
>
> Just do the minimal changes for the new format. Also demote the first
> section to the second level, i.e. make “Introduction” the same level
> as “Procedure’.
I feel like a good first step could've been to convert the
BreakingChanges.adoc document in-place to use the new format. Like that,
it would've become way easier to see what's actually changing. The
rename could've then been a 1:1 move.
Patrick
next prev parent reply other threads:[~2026-09-30 13:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 10:41 [RFC PATCH 0/4] doc: move BreakingChanges to a manpage kristofferhaugsbakk
2026-09-28 10:41 ` [RFC PATCH 1/4] doc: transform breaking changes doc " kristofferhaugsbakk
2026-09-30 13:28 ` Patrick Steinhardt [this message]
2026-09-30 14:17 ` Kristoffer Haugsbakk
2026-09-30 14:28 ` Patrick Steinhardt
2026-09-28 10:41 ` [RFC PATCH 2/4] doc: gitbreaking-changes: replace msg-ids with URLs kristofferhaugsbakk
2026-09-30 13:28 ` Patrick Steinhardt
2026-09-30 14:09 ` Kristoffer Haugsbakk
2026-09-30 19:45 ` Junio C Hamano
2026-10-01 6:27 ` Patrick Steinhardt
2026-10-03 11:52 ` Kristoffer Haugsbakk
2026-10-03 14:10 ` Kristoffer Haugsbakk
2026-10-04 2:31 ` Junio C Hamano
2026-10-06 16:38 ` Kristoffer Haugsbakk
2026-10-06 20:33 ` Junio C Hamano
2026-09-28 10:41 ` [RFC PATCH 3/4] doc: gitbreaking-changes: add note about living document kristofferhaugsbakk
2026-09-28 10:41 ` [RFC PATCH 4/4] doc: git: mention gitbreaking-changes(7) kristofferhaugsbakk
2026-10-08 19:27 ` [PATCH v2 0/5] doc: move BreakingChanges to a manpage kristofferhaugsbakk
2026-10-08 19:27 ` [PATCH v2 1/5] doc: BreakingChanges: transform " kristofferhaugsbakk
2026-10-08 19:46 ` D. Ben Knoble
2026-10-09 8:24 ` Kristoffer Haugsbakk
2026-10-08 19:27 ` [PATCH v2 2/5] doc: gitbreaking-changes: create from BreakingChanges kristofferhaugsbakk
2026-10-08 19:27 ` [PATCH v2 3/5] doc: gitbreaking-changes: replace msg-ids with URLs kristofferhaugsbakk
2026-10-08 19:27 ` [PATCH v2 4/5] doc: gitbreaking-changes: add note about living document kristofferhaugsbakk
2026-10-08 19:27 ` [PATCH v2 5/5] doc: gitbreaking-changes: move new-items discussion to the end kristofferhaugsbakk
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=ar0OicAaDipYx-xU@pks.im \
--to=ps@pks.im \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.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.