* Re: [PATCH 0/3] git-help -i (info): finishing touches
[not found] <1197279969-10613-1-git-send-email-gitster@pobox.com>
@ 2007-12-10 10:06 ` Junio C Hamano
2007-12-11 5:22 ` Christian Couder
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2007-12-10 10:06 UTC (permalink / raw)
To: git; +Cc: David Kastrup, Christian Couder
Junio C Hamano <gitster@pobox.com> writes:
> This series attempts to add finishing touches to "git help -i" (info)
> support.
Side note. The patches I sent out are queued for 'next', and I'll push
it out shortly. I am hoping, after this series graduates to 'master',
to be able to tag v1.5.4-rc0 and declare 'master' as feature complete
for now, and see everybody move to bugfix-only mode.
Currently, the man pages are sorted in $(wildcard) order in the main
menu, but I think:
* make git(7) the first node after Top;
* order the commands in the main @menu to follow the command-list.txt
categorization, and show Porcelains and then Plumbings, just like
git(7) does;
would make the organization better, but I did not do that tonight. I'd
leave that as an exercise to interested readers.
I also briefly considered rolling the manual pages into git.info which
is built from the user manual, but I decided against it for now. I
think the current organization of the user manual is good as a
standalone document, and making the manual set as its appendix is
possible but not necessary. I can be persuaded differently, though.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH 0/3] git-help -i (info): finishing touches
2007-12-10 10:06 ` [PATCH 0/3] git-help -i (info): finishing touches Junio C Hamano
@ 2007-12-11 5:22 ` Christian Couder
2007-12-11 5:27 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Christian Couder @ 2007-12-11 5:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Kastrup
Le lundi 10 décembre 2007, Junio C Hamano a écrit :
> Junio C Hamano <gitster@pobox.com> writes:
> > This series attempts to add finishing touches to "git help -i" (info)
> > support.
It looks like the patch series you talk about was not sent to the list.
In the last patch there is:
diff --git a/help.c b/help.c
index 9d7ad6f..c96b167 100644
--- a/help.c
+++ b/help.c
@@ -286,6 +286,7 @@ static void show_man_page(const char *git_cmd)
static void show_info_page(const char *git_cmd)
{
const char *page = cmd_to_page(git_cmd);
+ setenv("INFOPATH", GIT_INFO_PATH, 1);
execlp("info", "info", "gitman", page, NULL);
}
But I wonder if something like this would be better:
diff --git a/help.c b/help.c
index c96b167..933d850 100644
--- a/help.c
+++ b/help.c
@@ -255,23 +255,23 @@ static const char *cmd_to_page(const char *git_cmd)
}
}
-static void setup_man_path(void)
+static void prepend_to_env_path(const char *name, const char *value)
{
struct strbuf new_path;
- const char *old_path = getenv("MANPATH");
+ const char *old_path = getenv(name);
strbuf_init(&new_path, 0);
/* We should always put ':' after our path. If there is no
- * old_path, the ':' at the end will let 'man' to try
- * system-wide paths after ours to find the manual page. If
+ * old_path, the ':' at the end will let some commands
+ * like 'man' to try system-wide paths after ours. If
* there is old_path, we need ':' as delimiter. */
- strbuf_addstr(&new_path, GIT_MAN_PATH);
+ strbuf_addstr(&new_path, value);
strbuf_addch(&new_path, ':');
if (old_path)
strbuf_addstr(&new_path, old_path);
- setenv("MANPATH", new_path.buf, 1);
+ setenv(name, new_path.buf, 1);
strbuf_release(&new_path);
}
@@ -279,14 +279,14 @@ static void setup_man_path(void)
static void show_man_page(const char *git_cmd)
{
const char *page = cmd_to_page(git_cmd);
- setup_man_path();
+ prepend_to_env_path("MANPATH", GIT_MAN_PATH);
execlp("man", "man", page, NULL);
}
static void show_info_page(const char *git_cmd)
{
const char *page = cmd_to_page(git_cmd);
- setenv("INFOPATH", GIT_INFO_PATH, 1);
+ prepend_to_env_path("INFOPATH", GIT_INFO_PATH);
execlp("info", "info", "gitman", page, NULL);
}
Tell me if you want a proper path.
Christian.
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH 0/3] git-help -i (info): finishing touches
2007-12-11 5:22 ` Christian Couder
@ 2007-12-11 5:27 ` Junio C Hamano
0 siblings, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2007-12-11 5:27 UTC (permalink / raw)
To: Christian Couder; +Cc: git, David Kastrup
Christian Couder <chriscool@tuxfamily.org> writes:
> Le lundi 10 décembre 2007, Junio C Hamano a écrit :
>> Junio C Hamano <gitster@pobox.com> writes:
>> > This series attempts to add finishing touches to "git help -i" (info)
>> > support.
>
> It looks like the patch series you talk about was not sent to the list.
Hmph, it appears that there was a misconfiguration on my part to drive
send-email. Look into 'next' branch.
> In the last patch there is:
>
> diff --git a/help.c b/help.c
> index 9d7ad6f..c96b167 100644
> --- a/help.c
> +++ b/help.c
> @@ -286,6 +286,7 @@ static void show_man_page(const char *git_cmd)
> static void show_info_page(const char *git_cmd)
> {
> const char *page = cmd_to_page(git_cmd);
> + setenv("INFOPATH", GIT_INFO_PATH, 1);
> execlp("info", "info", "gitman", page, NULL);
> }
>
> But I wonder if something like this would be better:
I do not think so, as MANPATH has that funky semantics of "appending the
system path where a single colon separates an empty path component from
the rest." but I do not think there is anything like that in INFOPATH.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-12-11 5:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1197279969-10613-1-git-send-email-gitster@pobox.com>
2007-12-10 10:06 ` [PATCH 0/3] git-help -i (info): finishing touches Junio C Hamano
2007-12-11 5:22 ` Christian Couder
2007-12-11 5:27 ` Junio C Hamano
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).