From: Patrick Steinhardt <ps@pks.im>
To: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] doc: transform breaking changes doc to a manpage
Date: Wed, 30 Sep 2026 16:28:29 +0200 [thread overview]
Message-ID: <ar0cjf3rdrp6NAba@pks.im> (raw)
In-Reply-To: <2e53feae-94fe-4e1b-9665-2a639fe08515@app.fastmail.com>
On Wed, Sep 30, 2026 at 04:17:44PM +0200, Kristoffer Haugsbakk wrote:
> On Wed, Sep 30, 2026, at 15:28, Patrick Steinhardt wrote:
> > On Mon, Sep 28, 2026 at 12:41:25PM +0200, kristofferhaugsbakk@fastmail.com wrote:
> >> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
> > [...] 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.
>
> I know you are wondering out loud here to the fora. But just personally,
> I imagine that this will happen after Git 3.0:
>
> • A section at the end about Git 3.0 for historical interest as well as
> people on older versions who might be browsing outside of their
> installation (probably git-scm) (and who might be on pre-3.0)
> • Git 4.0 discussion before that, however hypothetical or distant the
> release date
Yeah, that's also mostly what I arrived at, too.
> >> 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.
>
> Like this?
>
> 1. Convert to the manpage format without changing the filename
> 2. Rename the file: pure rename without any other modifications
> 3. Resurrect `BreakingChanges.adoc` with one line that points to the new
> document
I guess (2) and (3) can easily be combined. I'd hope that Git still
detects this as a 1:1 rename.
Patrick
next prev parent reply other threads:[~2026-09-30 14:28 UTC|newest]
Thread overview: 24+ 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
2026-09-30 14:17 ` Kristoffer Haugsbakk
2026-09-30 14:28 ` Patrick Steinhardt [this message]
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-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=ar0cjf3rdrp6NAba@pks.im \
--to=ps@pks.im \
--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.