All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>
Cc: "D. Ben Knoble" <ben.knoble@gmail.com>,
	 git@vger.kernel.org,  "Patrick Steinhardt" <ps@pks.im>
Subject: Re: [PATCH v2 0/5] doc: move BreakingChanges to a manpage
Date: Thu, 22 Oct 2026 09:38:04 -0700	[thread overview]
Message-ID: <xmqq5wytitcj.fsf@gitster.g> (raw)
In-Reply-To: <a219a76c-faf5-4c50-9560-bf48f65167e4@app.fastmail.com> (Kristoffer Haugsbakk's message of "Thu, 22 Oct 2026 07:18:27 +0200")

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Wed, Oct 21, 2026, at 23:00, Junio C Hamano wrote:
>> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>>
>>> On Wed, Oct 21, 2026, at 18:50, Junio C Hamano wrote:
>>>> "D. Ben Knoble" <ben.knoble@gmail.com> writes:
>>>>> [snip]
>>>>
>>>> I do not know about "manual pages", but making this available from
>>>> "git help" would be good.  It raises a huge question about what to
>>>> do when Git 3.0 comes, though.  Are we going to change every section
>>>> and rewrite them to say "we used to do this differently before 3.0"?
>>>
>>> See me and Patrick’s subthread: <ar0OicAaDipYx-xU@pks.im>
>>>
>>> You could transform it into a section at the end for “what happened in 3.0” then introduce it with
>>>
>>>     These things changed in 3.0. They are written in the future tense
>>>     [?] is reading about what will happen coming from version 2.98 to
>>>     3.0.
>>>
>>> Then you wouldn’t need to change any of the rest of the text.
>>
>> The rewriting effort is not a major concern.  Rather, the question
>> is whether keeping such a historical document is worth it.  Do you
>> still care about what the major issues were when we transitioned
>> from Git 1.x to 2.0, for example?
>
> I’ve mostly just outlined how either approach can be handled. Personally
> I’m fine either way.
>
> As far as being a living document is concerned, discussions of old
> versions could be promptly deleted. People who are on older versions
> will have the relevant discussion in their installation. Beyond that
> people can use the power of version control spelunking.
>
> As an alternative you could keep just the previous breaking change
> discussion like mentioned in <ar0cjf3rdrp6NAba@pks.im>. Like, when
> you’re approaching Git 5.0 there will just be Git 5.0 and Git 4.0
> discussions left in the doc.

OK.  I was merely expressing my worry that it might be awkward post
the transition, but if the manpages (where? in section 7 perhaps) is
the easiest to arrange and will not be awkward to have after the
transition, then let's do that.

Thanks.

  reply	other threads:[~2026-10-22 16:38 UTC|newest]

Thread overview: 34+ 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
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
2026-10-20 13:31   ` [PATCH v2 0/5] doc: move BreakingChanges to a manpage Kristoffer Haugsbakk
2026-10-20 13:48     ` D. Ben Knoble
2026-10-20 13:53       ` Kristoffer Haugsbakk
2026-10-21 16:50       ` Junio C Hamano
2026-10-21 18:01         ` Kristoffer Haugsbakk
2026-10-21 21:00           ` Junio C Hamano
2026-10-22  5:18             ` Kristoffer Haugsbakk
2026-10-22 16:38               ` Junio C Hamano [this message]
2026-10-22  5:54             ` Patrick Steinhardt

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=xmqq5wytitcj.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kristofferhaugsbakk@fastmail.com \
    --cc=ps@pks.im \
    /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.