Git development
 help / color / mirror / Atom feed
From: "Julia Evans" <julia@jvns.ca>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Rewriting the Git tutorial to cover less content
Date: Fri, 25 Sep 2026 15:22:29 -0400	[thread overview]
Message-ID: <17c46e4e-a4f6-433e-8eea-c1e4eb28fdfd@app.fastmail.com> (raw)
In-Reply-To: <xmqqh5jdur4c.fsf@gitster.g>



On Fri, Sep 25, 2026, at 2:23 PM, Junio C Hamano wrote:
> "Julia Evans" <julia@jvns.ca> writes:
>
>>> See gittutorial(7) to get started, then see giteveryday(7) for
>>> a useful minimum set of commands.
>>
>> This is a nice friendly statement, but in my opinion `gittutorial` and
>> `giteveryday` really do not live up to what it promises, ...
>
> Yes, it outlived its time and the world has moved on.
>
>> I see a couple of possible strategies.
>>
>> * We can write new guides which are clearer
>> * We can link to outside resources (via https://git-scm.com/learn)
>>   which we think do a good job. Right now that page is pretty
>>   out of date and it would be very easy to improve.
>>
>> I think a mix of both is probably most realistic right now.
>
> Whatever we do, it is not enough that new guides are more clear than
> the current one.  The goal should be that it also is sufficient to
> replace the current one. 

I don't understand what you mean by "replace the current one". 
Some interpretations I can imagine:

1. The documentation remains internally consistent, like if it says
   "see <page> for <information>", then the information is in fact on that page
2. Any information explained in a guide must always be explained a
    in some guide in the future
3. We should aim to make guides more _useful_ over time: on average,
    a user reading the new version of the guide should come away having
    learned more relevant-to-them information about Git than with the
    old guide.
4. The original intent of a guide needs to be maintained.

I imagine everyone agrees that #1 is important. I spend most of my
time thinking about how to do a good job of #3.

> I do not know if we have bandwidth to keep external links fresh, and
> having a set of links to stale pages ourselves may hurt more than
> help.

We've had a list of links like this since 2013, at https://git-scm.com/doc/ext. 
It definitely has broken links and it would be pretty easy to update
some of them once, which would help in the short term.

  reply	other threads:[~2026-09-25 19:22 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 [this message]
2026-09-25 19:34               ` Junio C Hamano
2026-09-28 12:21                 ` Julia Evans
2026-09-28 15:16                   ` Junio C Hamano

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=17c46e4e-a4f6-433e-8eea-c1e4eb28fdfd@app.fastmail.com \
    --to=julia@jvns.ca \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox