Git development
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: Andreas Ericsson <ae@op5.se>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Jari Aalto <jari.aalto@cante.net>,
	git@vger.kernel.org
Subject: Re: [PATCH] Add commands that git-gc runs underneath
Date: Fri, 31 Aug 2007 21:25:31 +0200	[thread overview]
Message-ID: <85wsvbbj6c.fsf@lola.goethe.zz> (raw)
In-Reply-To: <46D7E058.9050001@op5.se> (Andreas Ericsson's message of "Fri\, 31 Aug 2007 11\:33\:12 +0200")

Andreas Ericsson <ae@op5.se> writes:

> Junio C Hamano wrote:
>> Andreas Ericsson <ae@op5.se> writes:
>>
>>> When gc was a shell-script, it was fairly easy to find out the command-
>>> sequence...
>>
>> Maybe referring more advanced/curious users to contrib/examples/
>> directory is a good idea, but not necessarily from manpages of
>> the commands that have been rewritten in C.
>>
>> I think contrib/examples/ needs a README file that effectively
>> say "these are the last versions of shell script implementation
>> of the commands before they were rewritten in C.  New features
>> may have been added to the built-in ones but these example
>> scripts are not kept up to date.  They are here to serve as
>> examples to show you how you would pipeline the plumbing level
>> commands."
>>
>
> Sensible, and also avoids the possible bitrot problem with the
> man-page should there be additional actions added to standard
> git-gc operations.

Let's just make all manual pages empty, and then we have solved all
manual page bitrot problems in one fell swoop.

Really: I don't see how this helps at all.  If I am interested in
seeing what operations git-gc performs, I am not interested in some
historical script's behavior.

Hiding that information into contrib/examples and telling people that
it may be wrong, anyway, is not really helpful as a way of documenting
git-gc's behavior.

Of _course_, _any_ useful documentation will have a "possible bitrot
problem with the man-page" whenever code is changed.  The solution is
not to make the manual pages as useless as possible so that nothing
can be subject to bitrot.  The solution is to update the information.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2007-08-31 19:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30  9:35 [PATCH] Add commands that git-gc runs underneath Jari Aalto
2007-08-30 10:08 ` Johannes Schindelin
2007-08-30 10:13   ` Andreas Ericsson
2007-08-30 11:58     ` Johannes Schindelin
2007-08-30 12:13       ` Andreas Ericsson
2007-08-30 12:15       ` Tom Clarke
2007-08-30 12:34       ` Theodore Tso
2007-08-30 21:33     ` Junio C Hamano
2007-08-31  9:33       ` Andreas Ericsson
2007-08-31 19:25         ` David Kastrup [this message]
2007-08-31 21:12         ` Junio C Hamano
2007-08-31 21:27           ` David Kastrup
2007-08-30 10:25   ` David Kastrup

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=85wsvbbj6c.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jari.aalto@cante.net \
    /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