From: Andreas Ericsson <ae@op5.se>
To: git@vger.kernel.org
Subject: Re: [ANNOUNCE] GIT 0.99.9g
Date: Sat, 12 Nov 2005 12:37:21 +0100 [thread overview]
Message-ID: <4375D3F1.2070506@op5.se> (raw)
In-Reply-To: <43750A53.9090602@zytor.com>
H. Peter Anvin wrote:
> Andreas Ericsson wrote:
>
>>>
>>> It's nice in concept, but I think there are a lot of reasons why this
>>> is a bad idea:
>>>
>>> - "man" doesn't handle it. It would be another thing if "man" could
>>> be taught to understand commands like "man cvs checkout" or "man git
>>> fetch".
>>
>>
>> This is moot. man-pages can still be named git-fetch.
>>
>
> Yes, of course, but that requires the user to be aware of yet another
> program-specific convention. I do believe that supporting hierarchial
> man pages would be a good thing, but one has to start that in the proper
> point.
>
Someone sent in a (broken) patch that pulls up the proper man-page for
git help <command>
It's a rather good idea, so I'll be working it into the C implementation
of git as soon as the core of it is implemented.
>>> - There is no general way to teach shells etc about it, for tab
>>> completion etc.
>>
>>
>> Add the lib directory to the path (for git-<tab><tab>) or have it
>> auto-evaluate the result of a git command-listing.
>
>
> ... which means the end user has to do something specific to their
> environment.
>
> All in all, I think the negatives outweigh the positives.
>
Perhaps, but allowing the possibility of splitting them can't be wrong.
When that's in place we only have to decide if we're going to or not.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2005-11-12 11:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-10 8:14 [ANNOUNCE] GIT 0.99.9g Junio C Hamano
2005-11-10 9:09 ` Jeff Garzik
2005-11-10 17:13 ` H. Peter Anvin
2005-11-10 18:34 ` Andreas Ericsson
2005-11-11 21:17 ` H. Peter Anvin
2005-11-12 11:37 ` Andreas Ericsson [this message]
2005-11-11 18:37 ` Junio C Hamano
2005-11-12 12:17 ` Andreas Ericsson
2005-11-14 7:46 ` Junio C Hamano
2005-11-14 9:23 ` Andreas Ericsson
2005-11-14 21:15 ` Junio C Hamano
2005-11-14 9:32 ` Petr Baudis
2005-11-10 9:54 ` Yaacov Akiba Slama
2005-11-10 19:55 ` Junio C Hamano
2005-11-10 17:09 ` H. Peter Anvin
2005-11-10 17:44 ` Junio C Hamano
2005-11-10 18:03 ` Petr Baudis
2005-11-10 18:31 ` Daniel Barkalow
2005-11-10 19:04 ` Junio C Hamano
2005-11-10 19:09 ` Daniel Barkalow
2005-11-10 19:32 ` Linus Torvalds
2005-11-10 19:43 ` Linus Torvalds
2005-11-11 21:18 ` H. Peter Anvin
2005-11-11 14:19 ` Johannes Schindelin
2005-11-11 17:46 ` H. Peter Anvin
2005-11-10 18:54 ` Jim Radford
2005-11-10 20:30 ` Andreas Ericsson
2005-11-10 20:48 ` Junio C Hamano
2005-11-11 18:23 ` Jim Radford
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=4375D3F1.2070506@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
/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).