[ANNOUNCE] Git 1.6.5.4

[ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

The latest maintenance release Git 1.6.5.4 is available at the
usual places:

  http://www.kernel.org/pub/software/scm/git/

  git-1.6.5.4.tar.{gz,bz2}			(source tarball)
  git-htmldocs-1.6.5.4.tar.{gz,bz2}		(preformatted docs)
  git-manpages-1.6.5.4.tar.{gz,bz2}		(preformatted docs)

The RPM binary packages for a few architectures are found in:

  RPMS/$arch/git-*-1.6.5.4-1.fc11.$arch.rpm	(RPM)

Contains some minor fixes that have been accumulated; all of them
appear in the upcoming 1.6.6 release as well.

This should fix the problem that man pages formatted on FC11 boxes are
littered with "man.base.url.for.relative.link" strings reported earlier
today.

Git v1.6.5.4 Release Notes
==========================

Fixes since v1.6.5.3
--------------------

 * "git help" (without argument) used to check if you are in a directory
   under git control. There was no breakage in behaviour per-se, but this
   was unnecessary.

 * "git prune-packed" gave progress output even when its standard error is
   not connected to a terminal; this caused cron jobs that run it to
   produce crufts.

 * "git pack-objects --all-progress" is an option to ask progress output
   from write-object phase _if_ progress output were to be produced, and
   shouldn't have forced the progress output.

 * "git apply -p<n> --directory=<elsewhere>" did not work well for a
   non-default value of n.

 * "git merge foo HEAD" was misparsed as an old-style invocation of the
   command and produced a confusing error message.  As it does not specify
   any other branch to merge, it shouldn't be mistaken as such.  We will
   remove the old style "git merge <message> HEAD <commit>..."  syntax in
   future versions, but not in this release,

 * "git merge -m <message> <branch>..." added the standard merge message
   on its own after user-supplied message, which should have overrided the
   standard one.

Other minor documentation updates are included.

----------------------------------------------------------------

Changes since v1.6.5.3 are as follows:

David Aguilar (1):
      help: Do not unnecessarily look for a repository

David Soria Parra (1):
      Documentation: Document --branch option in git clone synopsis

Greg Price (1):
      Documentation: undocument gc'd function graph_release()

Jeff King (1):
      prune-packed: only show progress when stderr is a tty

Junio C Hamano (7):
      builtin-apply.c: pay attention to -p<n> when determining the name
      Do not misidentify "git merge foo HEAD" as an old-style invocation
      merge: do not add standard message when message is given with -m option
      Prepare for 1.6.5.4
      Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make
      Unconditionally set man.base.url.for.relative.links
      Git 1.6.5.4

Michael J Gruber (1):
      Documentation: Fix a few i.e./e.g. mix-ups

Nicolas Pitre (1):
      pack-objects: split implications of --all-progress from progress activation

Stephen Boyd (1):
      instaweb: restart server if already running

Re: [ANNOUNCE] Git 1.6.5.4

[Jeff King]

On Thu, Dec 03, 2009 at 01:21:13AM -0800, Junio C Hamano wrote:

>  * "git pack-objects --all-progress" is an option to ask progress output
>    from write-object phase _if_ progress output were to be produced, and
>    shouldn't have forced the progress output.

Shouldn't this actually be --all-progress-implied? Nico's patch
intentionally kept --all-progress with the same behavior.

-Peff

Re: [ANNOUNCE] Git 1.6.5.4

[Andreas Schwab]

Junio C Hamano <gitster@pobox.com> writes:

>       Unconditionally set man.base.url.for.relative.links

rm -f git-add.1 && \
        xmlto -m manpage-normal.xsl  --stringparam man.base.url.for.relative.links= man git-add.xml
xmlto: unrecognized option '--stringparam'
make[1]: *** [git-add.1] Error 1

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [ANNOUNCE] Git 1.6.5.4

[Michael J Gruber]

Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>>       Unconditionally set man.base.url.for.relative.links
> 
> rm -f git-add.1 && \
>         xmlto -m manpage-normal.xsl  --stringparam man.base.url.for.relative.links= man git-add.xml
> xmlto: unrecognized option '--stringparam'
> make[1]: *** [git-add.1] Error 1
> 
> Andreas.
> 

and

uname -a
xmlto --version

says?

Michael

Re: [ANNOUNCE] Git 1.6.5.4

[Andreas Schwab]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>>>       Unconditionally set man.base.url.for.relative.links
>> 
>> rm -f git-add.1 && \
>>         xmlto -m manpage-normal.xsl  --stringparam man.base.url.for.relative.links= man git-add.xml
>> xmlto: unrecognized option '--stringparam'
>> make[1]: *** [git-add.1] Error 1
>> 
>> Andreas.
>> 
>
> and
>
> uname -a
> xmlto --version
>
> says?

xmlto version 0.0.18

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [ANNOUNCE] Git 1.6.5.4

[Michael J Gruber]

Andreas Schwab venit, vidit, dixit 03.12.2009 14:50:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>>       Unconditionally set man.base.url.for.relative.links
>>>
>>> rm -f git-add.1 && \
>>>         xmlto -m manpage-normal.xsl  --stringparam man.base.url.for.relative.links= man git-add.xml
>>> xmlto: unrecognized option '--stringparam'
>>> make[1]: *** [git-add.1] Error 1
>>>
>>> Andreas.
>>>
>>
>> and
>>
>> uname -a
>> xmlto --version
>>
>> says?
> 
> xmlto version 0.0.18
> 
> Andreas.
> 

Now that predates Git quite a bit (2004-01-21)...
I think we can require at least 0.0.20, which is in Debian Lenny and
Fedora 9, for example. I think that should have it. (I'm not sure, they
don't use a proper vcs ;) ).

Michael

Re: [ANNOUNCE] Git 1.6.5.4

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

Michael J Gruber wrote:
>>> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>> xmlto version 0.0.18
[...]
> Now that predates Git quite a bit (2004-01-21)...
> I think we can require at least 0.0.20, which is in Debian Lenny and
> Fedora 9, for example. I think that should have it. (I'm not sure, they
> don't use a proper vcs ;) ).

xmlto-0.0.18 is what's in RHEL/CentOS 5.  It would be nice to be able
to build git docs there, which works pretty well in general (I
believe).

I built 1.6.6.rc1 on CentOS 5.4 last night with Junio's first patch
for this, which only called --stringparam if MAN_BASE_URL was set.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A common mistake people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
    -- Douglas Adams


[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]

Re: [ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

> Michael J Gruber wrote:
>>>> Andreas Schwab venit, vidit, dixit 03.12.2009 13:03:
>>> xmlto version 0.0.18
> [...]
>> Now that predates Git quite a bit (2004-01-21)...
>> I think we can require at least 0.0.20, which is in Debian Lenny and
>> Fedora 9, for example. I think that should have it. (I'm not sure, they
>> don't use a proper vcs ;) ).
>
> xmlto-0.0.18 is what's in RHEL/CentOS 5.  It would be nice to be able
> to build git docs there, which works pretty well in general (I
> believe).
>
> I built 1.6.6.rc1 on CentOS 5.4 last night with Junio's first patch
> for this, which only called --stringparam if MAN_BASE_URL was set.

I did the second one after seeing that both my Debian box and the k.org
machine that manpages tarballs are made (FC11 IIRC) had that option, and
my impression has been that it usually is safe to say "even Debian has it,
and there wouldn't be many things older than that distro", but that is
apparently not true.

Either we require 0.0.20 or we revert the tip one on this topic.  I think
the latter is a safe thing to do.

Thanks for a quick report and analysis.

Re: [ANNOUNCE] Git 1.6.5.4

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

Junio C Hamano wrote:
> I did the second one after seeing that both my Debian box and the
> k.org machine that manpages tarballs are made (FC11 IIRC) had that
> option, and my impression has been that it usually is safe to say
> "even Debian has it, and there wouldn't be many things older than
> that distro", but that is apparently not true.

Heh, that surely used to be a very good rule of thumb.  Perhaps these
days a rule of whichever is older Debian stable or current RHEL/CentOS
would suffice?

> Either we require 0.0.20 or we revert the tip one on this topic.  I
> think the latter is a safe thing to do.

That sounds good to me.  I'd like to get the EPEL builds for
RHEL/CentOS updated sometime soon, as they're currently still on
1.5.5.6 and that lacks too many of the great improvements in newer git
releases.  Not having to patch for building the docs is one less thing
to worry about.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rowe's Rule: The odds are five to six that the light at the end of the
tunnel is the headlight of an oncoming train.
    -- Paul Dickson


[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]

Re: [ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

>> Either we require 0.0.20 or we revert the tip one on this topic.  I
>> think the latter is a safe thing to do.
>
> That sounds good to me.  I'd like to get the EPEL builds for
> RHEL/CentOS updated sometime soon, as they're currently still on
> 1.5.5.6 and that lacks too many of the great improvements in newer git
> releases.  Not having to patch for building the docs is one less thing
> to worry about.

This is what I plan to use.

-- >8 ---
From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 3 Dec 2009 11:12:32 -0800
Subject: [PATCH] Documentation: xmlto 0.0.18 does not know --stringparam

Newer DocBook stylesheets want man.base.url.for.relative.links
parameter set when formatting manpages with external references
to turn them into full URLs, and leave a helpful "you should
set this parameter" message in the output.  Earlier we added
the MAN_BASE_URL make variable to specify the value for it.

When MAN_BASE_URL is not given, it ought to be safe to set the
parameter to empty; it would result in an empty leading path for
older stylesheets that ignore the parameter, and newer ones
would produce the same "relative URL" without the message.

Unfortunately, older xmlto (at least version 0.0.18 released in
early 2004 that comes with RHEL/CentOS 5) does not understand
the --stringparam command line option, so we cannot add the
parameter definition unconditionally to the command line.  Work
it around by passing the parameter only when set.

If you do not have a suitable URL prefix, you can pass a quoted empty
string to it, like so:

    $ make MAN_BASE_URL='""'

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/Makefile |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/Documentation/Makefile b/Documentation/Makefile
index d4c05ca..1c9dfce 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -108,7 +108,14 @@ endif
 # use MAN_BASE_URL=http://www.kernel.org/pub/software/scm/git/docs/
 # but distros may want to set it to /usr/share/doc/git-core/docs/ or
 # something like that.
+#
+# As older stylesheets simply ignore this parameter, it ought to be
+# safe to set it to empty string when the base URL is not specified,
+# but unfortunately we cannot do so unconditionally because at least
+# xmlto 0.0.18 is reported to lack --stringparam option.
+ifdef MAN_BASE_URL
 XMLTO_EXTRA += --stringparam man.base.url.for.relative.links=$(MAN_BASE_URL)
+endif
 
 # If your target system uses GNU groff, it may try to render
 # apostrophes as a "pretty" apostrophe using unicode.  This breaks
-- 
1.6.6.rc1.5.ge21a85

Re: [ANNOUNCE] Git 1.6.5.4

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

Junio C Hamano wrote:
> This is what I plan to use.
>
> -- >8 ---
> From: Junio C Hamano <gitster@pobox.com>
> Date: Thu, 3 Dec 2009 11:12:32 -0800
> Subject: [PATCH] Documentation: xmlto 0.0.18 does not know --stringparam
>
> Newer DocBook stylesheets want man.base.url.for.relative.links
> parameter set when formatting manpages with external references
> to turn them into full URLs, and leave a helpful "you should
> set this parameter" message in the output.  Earlier we added
> the MAN_BASE_URL make variable to specify the value for it.
>
> When MAN_BASE_URL is not given, it ought to be safe to set the
> parameter to empty; it would result in an empty leading path for
> older stylesheets that ignore the parameter, and newer ones
> would produce the same "relative URL" without the message.
>
> Unfortunately, older xmlto (at least version 0.0.18 released in
> early 2004 that comes with RHEL/CentOS 5) does not understand
> the --stringparam command line option, so we cannot add the
> parameter definition unconditionally to the command line.  Work
> it around by passing the parameter only when set.

Is it worth sidestepping the xmlto part entirely?  If we set this
directly in a .xsl file, it will work on older systems without any
effort.  Then we can default MAN_BASE_URL to something and let distro
packagers override it.

I tested with this in Documentation/manpage-base.xsl on a CentOS 5 box
and it builds fine, leaving no cruft in the man pages regarding the
man.base.url...

<!-- set a base URL for relative links -->
<xsl:param name="man.base.url.for.relative.links"
       >/path/to/git/docs</xsl:param>

Of course, the relative links looked just like they did in older
docbook releases:

       1. Everyday Git
          everyday.html

Is it worth the effort to have @@MAN_BASE_URL@@ in
Documentation/manpage-base.xsl or similar and replace it at build
time?

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Just because everything is different doesn't mean anything has
changed.
    -- Irene Peter


[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]

Re: [ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

> I tested with this in Documentation/manpage-base.xsl on a CentOS 5 box
> and it builds fine, leaving no cruft in the man pages regarding the
> man.base.url...
>
> <!-- set a base URL for relative links -->
> <xsl:param name="man.base.url.for.relative.links"
>        >/path/to/git/docs</xsl:param>
>
> Of course, the relative links looked just like they did in older
> docbook releases:
>
>        1. Everyday Git
>           everyday.html
>
> Is it worth the effort to have @@MAN_BASE_URL@@ in
> Documentation/manpage-base.xsl or similar and replace it at build
> time?

I think it depends on the likelihood that a distro has xmlto so old that
it does not understand --stringparam yet it uses stylesheet so new that
setting the parameter makes a positive difference (either it gives the
full URL or at least squelches the "You should define the parameter"
noise) in the output.

I am guessing that the answer would be that is a very unlikely combination
and not worth worrying about it, but I've been wrong before in this exact
area ;-)

Re: [ANNOUNCE] Git 1.6.5.4

[Eugene Sajine]

On Thu, Dec 3, 2009 at 5:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Todd Zullinger <tmz@pobox.com> writes:
>
>> I tested with this in Documentation/manpage-base.xsl on a CentOS 5 box
>> and it builds fine, leaving no cruft in the man pages regarding the
>> man.base.url...
>>
>> <!-- set a base URL for relative links -->
>> <xsl:param name="man.base.url.for.relative.links"
>>        >/path/to/git/docs</xsl:param>
>>
>> Of course, the relative links looked just like they did in older
>> docbook releases:
>>
>>        1. Everyday Git
>>           everyday.html
>>
>> Is it worth the effort to have @@MAN_BASE_URL@@ in
>> Documentation/manpage-base.xsl or similar and replace it at build
>> time?
>
> I think it depends on the likelihood that a distro has xmlto so old that
> it does not understand --stringparam yet it uses stylesheet so new that
> setting the parameter makes a positive difference (either it gives the
> full URL or at least squelches the "You should define the parameter"
> noise) in the output.
>
> I am guessing that the answer would be that is a very unlikely combination
> and not worth worrying about it, but I've been wrong before in this exact
> area ;-)


Hello,

We have RH with xmlto 0.0.18. I was getting ready to update our
installation to 1.6.5.4, but as i understand the documentation will
not be fully available untill this issue is resolved. Could you,
please, advise if this is going to be in next 1.6.5.5?

Thanks,
Eugene

Re: [ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

Eugene Sajine <euguess@gmail.com> writes:

> We have RH with xmlto 0.0.18. I was getting ready to update our
> installation to 1.6.5.4, but as i understand the documentation will
> not be fully available untill this issue is resolved. Could you,
> please, advise if this is going to be in next 1.6.5.5?

I've applied the patch in the thread you are responding to already on
'maint' so it will appear in both 1.6.5.5 and 1.6.6.  In the meantime, if
you want to run 1.6.5.4 or preferably 1.6.6-rc1, you can locally revert
8dd35c7 (Unconditionally set man.base.url.for.relative.links, 2009-12-03).

Re: [ANNOUNCE] Git 1.6.5.4

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> Eugene Sajine <euguess@gmail.com> writes:
>
>> We have RH with xmlto 0.0.18. I was getting ready to update our
>> installation to 1.6.5.4, but as i understand the documentation will
>> not be fully available untill this issue is resolved. Could you,
>> please, advise if this is going to be in next 1.6.5.5?
>
> I've applied the patch in the thread you are responding to already on
> 'maint' so it will appear in both 1.6.5.5 and 1.6.6.  In the meantime, if
> you want to run 1.6.5.4 or preferably 1.6.6-rc1, you can locally revert
> 8dd35c7 (Unconditionally set man.base.url.for.relative.links,
> 2009-12-03).

Also, one can download the man pages from git.git :

# in a clone of git://git.kernel.org/pub/scm/git/git.git
git archive --format=tar origin/man | tar -x -C /usr/share/man/ -vf -

(or leave with 1.6.5.5 and the docs of 1.6.5.4 for some time)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [ANNOUNCE] Git 1.6.5.4

[Andreas Schwab]

Junio C Hamano <gitster@pobox.com> writes:

> I think it depends on the likelihood that a distro has xmlto so old that
> it does not understand --stringparam yet it uses stylesheet so new that
> setting the parameter makes a positive difference (either it gives the
> full URL or at least squelches the "You should define the parameter"
> noise) in the output.

openSUSE 11.2, for example.  Its xmlto has a non-standard --xsltopts
option that passes its argument down to xsltproc.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> I think it depends on the likelihood that a distro has xmlto so old that
>> it does not understand --stringparam yet it uses stylesheet so new that
>> setting the parameter makes a positive difference (either it gives the
>> full URL or at least squelches the "You should define the parameter"
>> noise) in the output.
>
> openSUSE 11.2, for example.  Its xmlto has a non-standard --xsltopts
> option that passes its argument down to xsltproc.

Ok, as I said that I've been wrong before in this area ;-)

I don't think I will have much time for git today, and it would be
appreciated if somebody can work on this and send a tested patch that
applies cleanly on top of 'maint' to implement the @@MAN_BASE_URL@@
replacement from manpage-base.xsl.in to manpage-base.xsl as Todd suggested
earlier.

Re: [ANNOUNCE] Git 1.6.5.4

[Todd Zullinger]

Junio C Hamano wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> I think it depends on the likelihood that a distro has xmlto so old that
>>> it does not understand --stringparam yet it uses stylesheet so new that
>>> setting the parameter makes a positive difference (either it gives the
>>> full URL or at least squelches the "You should define the parameter"
>>> noise) in the output.
>>
>> openSUSE 11.2, for example.  Its xmlto has a non-standard --xsltopts
>> option that passes its argument down to xsltproc.
>
> Ok, as I said that I've been wrong before in this area ;-)
>
> I don't think I will have much time for git today, and it would be
> appreciated if somebody can work on this and send a tested patch that
> applies cleanly on top of 'maint' to implement the @@MAN_BASE_URL@@
> replacement from manpage-base.xsl.in to manpage-base.xsl as Todd suggested
> earlier.

Something like this perhaps?  I tested it with 1.6.5.4 on Fedora 10,
12 and CentOS 5.4 but it could surely use more eyes and testing to
ensure it works as it should and doesn't have unintended negative
effects on make clean and such.

This does set MAN_BASE_URL unconditionally, pointing to kernel.org.
That way anyone building with recent DocBook and taking no new action
will have something useful in the man page links.

I noticed on Fedora 12 that email addresses get added to the NOTES
section.  For example, git-branch(1) has:

Documentation by Junio C Hamano and the git-list <git@vger.kernel.org[4]>.
...
NOTES
...
4. git@vger.kernel.org
   mailto:git@vger.kernel.org

That must be something new in DocBook, as it doesn't occur in the
Fedora 10 builds.  It's a little extraneous, but not harmful I guess.

--- >8 ---
From: Todd Zullinger <tmz@pobox.com>
Date: Fri, 4 Dec 2009 12:53:21 -0500
Subject: [PATCH] Documentation: Avoid use of xmlto --stringparam

The --stringparam option is not available on older xmlto versions.
Instead, set man.base.url.for.relative.links via a .xsl file.  Older
docbook versions will ignore this without causing grief to users of
older xmlto versions.

Signed-off-by: Todd Zullinger <tmz@pobox.com>
---
 Documentation/.gitignore              |    1 +
 Documentation/Makefile                |   23 ++++++++++++-----------
 Documentation/manpage-base-url.xsl.in |   10 ++++++++++
 3 files changed, 23 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/manpage-base-url.xsl.in

diff --git a/Documentation/.gitignore b/Documentation/.gitignore
index d8edd90..1c3a9fe 100644
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -8,3 +8,4 @@ gitman.info
 howto-index.txt
 doc.dep
 cmds-*.txt
+manpage-base-url.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 1c9dfce..1c867fa 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -104,18 +104,15 @@ XMLTO_EXTRA += -m manpage-suppress-sp.xsl
 endif
 
 # Newer DocBook stylesheet emits warning cruft in the output when
-# this is not set, and if set it shows an absolute link.  We can
-# use MAN_BASE_URL=http://www.kernel.org/pub/software/scm/git/docs/
-# but distros may want to set it to /usr/share/doc/git-core/docs/ or
-# something like that.
+# this is not set, and if set it shows an absolute link.  Older
+# stylesheets simply ignore this parameter.
 #
-# As older stylesheets simply ignore this parameter, it ought to be
-# safe to set it to empty string when the base URL is not specified,
-# but unfortunately we cannot do so unconditionally because at least
-# xmlto 0.0.18 is reported to lack --stringparam option.
-ifdef MAN_BASE_URL
-XMLTO_EXTRA += --stringparam man.base.url.for.relative.links=$(MAN_BASE_URL)
+# Distros may want to use MAN_BASE_URL=file:///path/to/git/docs/
+# or similar.
+ifndef MAN_BASE_URL
+MAN_BASE_URL = http://www.kernel.org/pub/software/scm/git/docs/
 endif
+XMLTO_EXTRA += -m manpage-base-url.xsl
 
 # If your target system uses GNU groff, it may try to render
 # apostrophes as a "pretty" apostrophe using unicode.  This breaks
@@ -244,6 +241,7 @@ clean:
 	$(RM) howto-index.txt howto/*.html doc.dep
 	$(RM) technical/api-*.html technical/api-index.txt
 	$(RM) $(cmds_txt) *.made
+	$(RM) manpage-base-url.xsl
 
 $(MAN_HTML): %.html : %.txt
 	$(QUIET_ASCIIDOC)$(RM) $@+ $@ && \
@@ -251,7 +249,10 @@ $(MAN_HTML): %.html : %.txt
 		$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) -o $@+ $< && \
 	mv $@+ $@
 
-%.1 %.5 %.7 : %.xml
+manpage-base-url.xsl: manpage-base-url.xsl.in
+	sed "s|@@MAN_BASE_URL@@|$(MAN_BASE_URL)|" $< > $@
+
+%.1 %.5 %.7 : %.xml manpage-base-url.xsl
 	$(QUIET_XMLTO)$(RM) $@ && \
 	xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) man $<
 
diff --git a/Documentation/manpage-base-url.xsl.in b/Documentation/manpage-base-url.xsl.in
new file mode 100644
index 0000000..e800904
--- /dev/null
+++ b/Documentation/manpage-base-url.xsl.in
@@ -0,0 +1,10 @@
+<!-- manpage-base-url.xsl:
+     special settings for manpages rendered from newer docbook -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+		version="1.0">
+
+<!-- set a base URL for relative links -->
+<xsl:param name="man.base.url.for.relative.links"
+	>@@MAN_BASE_URL@@</xsl:param>
+
+</xsl:stylesheet>
-- 
1.6.6.rc1

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The world keeps ending but new people too dumb to know it keep showing
up as if the fun's just started.

Re: [ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

> This does set MAN_BASE_URL unconditionally, pointing to kernel.org.
> That way anyone building with recent DocBook and taking no new action
> will have something useful in the man page links.

I'd rather see it set to an empty string by default which will essentially
keep the old output.  An alternative would be to default to the location
the install-html target installs, i.e. $HOME/share/doc/git-doc pointed by
$(htmldir) in Documentation/Makefile.

Distro people should be strongly encouraged to repoint the variable to
somewhere local that does not require connections to k.org or anywhere
outside the end-user's installation, but that is a slightly separate and
different topic.

Re: [ANNOUNCE] Git 1.6.5.4

[Junio C Hamano]

Todd Zullinger <tmz@pobox.com> writes:

> Something like this perhaps?  I tested it with 1.6.5.4 on Fedora 10,
> 12 and CentOS 5.4 but it could surely use more eyes and testing to
> ensure it works as it should and doesn't have unintended negative
> effects on make clean and such.

Thanks (and thanks Andreas for pointing out a yet another distro that is
different).  I think the patch makes sense.

> This does set MAN_BASE_URL unconditionally, pointing to kernel.org.

I'd change this to point at "file://$(htmldir)/", though.

Re: [ANNOUNCE] Git 1.6.5.4

[Todd Zullinger]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

Junio C Hamano wrote:
>> This does set MAN_BASE_URL unconditionally, pointing to kernel.org.
>
> I'd change this to point at "file://$(htmldir)/", though.

Thanks.  I can delete the mail with an updated patch that I started
over the weekend and didn't finish, which did that as well. ;)

Many thanks for all your hard work Junio.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aim Low, Reach Your Goals, Avoid Disappointment.


[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]