git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	John Keeping <john@keeping.me.uk>,
	git@vger.kernel.org, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Max Horn <max@quendi.de>
Subject: Re: [PATCH] Rename {git- => git}remote-helpers.txt
Date: Fri, 1 Feb 2013 02:33:52 -0500	[thread overview]
Message-ID: <20130201073352.GB970@sigill.intra.peff.net> (raw)
In-Reply-To: <7v7gmsd26o.fsf@alter.siamese.dyndns.org>

On Thu, Jan 31, 2013 at 09:37:51PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > What was the original rationale for the "gitfoo" form? Was it just to
> > visually distinguish command manpages from non-command manpages? I can't
> > remember the origins now.
> 
> b27a23e (Documentation: convert tutorials to man pages, 2008-05-24)
> turns "tutorial.txt" into "gittutorial.txt".  Before that, there
> were git{attributes,cli,ignore,hooks,modules}.txt.  They were added
> in this order, which reveals the true reason:
> 
>     hooks.txt
>     gitignore.txt
>     gitmodules.txt
>     gitcli.txt
>     hooks.txt => githooks.txt
>     gitatributes.txt
> 
> Originally, we did not intend to name them as "git$concept.txt";
> instead, we just said "$concept.txt".  Hooks are "hooks", and we
> know we are discussing hooks in the context of Git, there was no
> reason to say "githooks".

Yes, but if we are going to install a manpage, we must include "git"
somewhere in the name since that context is lost in the global manpage
database. So we need "githooks.txt" or "git-hooks.txt".

> "gitignore" was about the file format,
> and it would have been insane to call it "ignore.txt".  The same
> applies to "gitmodules.txt".

Right. So we have some that must be "gitfoo", and others that do not
care. If we turned "githooks" into "git-hooks" and removed the "is it a
command?" magic from "git help", then "git help hooks" would still find
hooks. And likewise, "git help gitignore" would still find "gitignore".
But you could no longer say "git help ignore" to find "gitignore".

Which personally I am OK with. It is not a sensible thing to ask for;
the concept is not "ignore", but rather "the gitignore file".

> In other way, I think this wasn't designed, but organically grown.

Like many parts of git. :) I am starting to think it has grown in an
unnecessarily complex direction, and we would be much happier just
calling all of the "concept" documentation "git-".

The steps I see are:

  1. Modify builtin/help.c, like:

diff --git a/builtin/help.c b/builtin/help.c
index 6067a61..1eca4ea 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -308,10 +308,8 @@ static const char *cmd_to_page(const char *git_cmd)
 		return "git";
 	else if (!prefixcmp(git_cmd, "git"))
 		return git_cmd;
-	else if (is_git_command(git_cmd))
-		return prepend("git-", git_cmd);
 	else
-		return prepend("git", git_cmd);
+		return prepend("git-", git_cmd);
 }
 
 static void setup_man_path(void)


  2. Rename the "concept" files like:

 Documentation/{gitcli.txt => git-cli.txt}                             | 0
 Documentation/{gitcore-tutorial.txt => git-core-tutorial.txt}         | 0
 Documentation/{gitcredentials.txt => git-credentials.txt}             | 0
 Documentation/{gitcvs-migration.txt => git-cvs-migration.txt}         | 0
 Documentation/{gitdiffcore.txt => git-diffcore.txt}                   | 0
 Documentation/{gitglossary.txt => git-glossary.txt}                   | 0
 Documentation/{githooks.txt => git-hooks.txt}                         | 0
 Documentation/{gitnamespaces.txt => git-namespaces.txt}               | 0
 Documentation/{gitrepository-layout.txt => git-repository-layout.txt} | 0
 Documentation/{gitrevisions.txt => git-revisions.txt}                 | 0
 Documentation/{gittutorial-2.txt => git-tutorial-2.txt}               | 0
 Documentation/{gittutorial.txt => git-tutorial.txt}                   | 0
 Documentation/{gitworkflows.txt => git-workflows.txt}                 | 0


  3. Teach Documentation/Makefile about the new filenames. MAN1_TXT
     includes git-*.txt, which is no longer right. I think we'd need to
     just filter out what is in MAN5_TXT and MAN7_TXT.

  4. Replace the rename "gitfoo" above with a "see git-foo..." pointer.
     Users of "git help foo" would not ever see this, but people who
     have trained their fingers to type "man gitfoo" would, along with
     anybody following an outdated HTML link.

  5. Update internal references to "linkgit:gitfoo" to point to
     "git-foo".

Hmm. That really does not seem so bad. The biggest downside is the
people who have to see the redirect made in step 4.

But I have not thought about it too hard, so maybe there is something
else I'm not seeing.

-Peff

  reply	other threads:[~2013-02-01  7:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-30 20:11 git-remote-helpers.txt: should it be gitremote-helpers.txt? John Keeping
2013-01-30 20:28 ` Junio C Hamano
2013-01-31 20:08   ` [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt John Keeping
2013-01-31 20:18     ` Matthieu Moy
2013-01-31 20:36       ` Junio C Hamano
2013-01-31 21:59         ` [PATCH] Rename {git- => git}remote-helpers.txt John Keeping
2013-01-31 22:13           ` Junio C Hamano
2013-01-31 22:28             ` John Keeping
2013-01-31 22:43               ` Junio C Hamano
2013-01-31 22:56                 ` John Keeping
2013-01-31 23:49                   ` Junio C Hamano
2013-01-31 22:33           ` Jeff King
2013-01-31 22:48             ` Junio C Hamano
2013-01-31 23:04             ` Jonathan Nieder
2013-01-31 23:11               ` Junio C Hamano
2013-01-31 23:13                 ` Jonathan Nieder
2013-02-01  5:03               ` Jeff King
2013-02-01  5:37                 ` Junio C Hamano
2013-02-01  7:33                   ` Jeff King [this message]
2013-02-01  8:25                     ` Jeff King
2013-02-01  8:26                       ` [PATCH 1/2] Documentation/Makefile: clean up MAN*_TXT lists Jeff King
2013-02-01 19:20                         ` Jonathan Nieder
2013-02-01 19:38                           ` Junio C Hamano
2013-02-01 19:38                           ` Jeff King
2013-02-01 19:41                             ` Jeff King
2013-02-01  8:27                       ` [PATCH 2/2] docs: convert "concept" manpages to git-* Jeff King
2013-02-01 19:25                         ` Jonathan Nieder
2013-02-01 18:52                     ` [PATCH] Rename {git- => git}remote-helpers.txt Junio C Hamano
2013-02-01 19:00                       ` Jeff King
2013-02-01 22:15                         ` Junio C Hamano
2013-01-31 22:28     ` [PATCH] gitremote-helpers.txt: rename from git-remote-helpers.txt Tomas Carnecky
2013-01-31 22:45       ` 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=20130201073352.GB970@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=john@keeping.me.uk \
    --cc=jrnieder@gmail.com \
    --cc=max@quendi.de \
    /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;
as well as URLs for NNTP newsgroup(s).