From: Junio C Hamano <gitster@pobox.com>
To: "Julia Evans" <julia@jvns.ca>
Cc: git@vger.kernel.org
Subject: Re: Rewriting the Git tutorial to cover less content
Date: Mon, 28 Sep 2026 08:16:17 -0700 [thread overview]
Message-ID: <xmqqh5j9o18e.fsf@gitster.g> (raw)
In-Reply-To: <7004c3b1-2100-4a90-9815-2a679ceb25b2@app.fastmail.com> (Julia Evans's message of "Mon, 28 Sep 2026 08:21:11 -0400")
"Julia Evans" <julia@jvns.ca> writes:
>> Dealing with broken links is easier as we can just remove them.
>> Noticing a link that points at an unmaintained stale document that
>> describes what used to be relevant but no longer in today's
>> environment and replacing it with something more relevant was what I
>> am worried about.
>
> Thanks, this is helpful. Let me try to rephrase to see if I understand,
> let me know if I'm understanding wrong.
In the above, I was talking about the reference links that are stale
at https://git-scm.com/doc/ext which you mentioned. You said that
it is easy to update broken links there. I wanted to point out that
there are two kinds of staleness, one that you can validate by
clicking on the link and seeing 404 (your "easy" kind), and the
other that you have to read what you are given by clicking on the
link and evaluate its relevance in today's world (which is much
harder).
So, while I do agree with everything you said in the two paragraphs
below, I do not think these two paragraphs have any rephrased
version of what I wanted to say ?-).
> When possible, it's better to split up changes into smaller pieces so
> that they can be reviewed more easily.
>
> For this change, it would help to split it up into two different patch series:
> "remove tutorial" and "add new tutorial", where the first patch series
> deletes all references to the tutorial. If we do it this way, we can
> both make sure that there isn't any content that we regret deleting,
> and lets us take a look at the documents that reference the tutorial too.
Yes, feeding smaller independent pieces is a format that is easier
to review. If the end result is that the old tutorial is gone and
replaced by the new tutorial, that would be what we want. When we
added gittutorial-2, we did not remove gittutorial, probably because
nobody had the guts to say "let's rip out what Linus wrote, it is so
out of date and gives much less relevant information useful in
today's world".
I do not want to repeat that; it is like https://xkcd.com/927/.
prev parent reply other threads:[~2026-09-28 15:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 19:29 [PATCH] doc: add more AsciiDoc cross-references Julia Evans via GitGitGadget
2026-09-22 20:20 ` Junio C Hamano
2026-09-22 20:54 ` Julia Evans
2026-09-23 21:40 ` Jeff King
2026-09-24 12:30 ` Julia Evans
2026-09-24 15:55 ` Jeff King
2026-09-24 17:15 ` Junio C Hamano
2026-09-24 17:22 ` Julia Evans
2026-09-24 18:17 ` Junio C Hamano
2026-09-24 18:42 ` Jeff King
2026-09-23 19:06 ` Kristoffer Haugsbakk
2026-09-23 22:00 ` Jeff King
2026-09-25 0:52 ` [PATCH v2] " Julia Evans via GitGitGadget
2026-09-25 8:27 ` Jeff King
2026-09-25 16:08 ` Rewriting the Git tutorial to cover less content Julia Evans
2026-09-25 16:47 ` Junio C Hamano
2026-09-25 17:25 ` Julia Evans
2026-09-25 18:23 ` Junio C Hamano
2026-09-25 19:22 ` Julia Evans
2026-09-25 19:34 ` Junio C Hamano
2026-09-28 12:21 ` Julia Evans
2026-09-28 15:16 ` Junio C Hamano [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=xmqqh5j9o18e.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=julia@jvns.ca \
/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