[ANNOUNCE] Git 1.6.5.4

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

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

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

-Peff

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

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 venit, vidit, dixit 03.12.2009 13:03:

and

uname -a xmlto --version

says?

Michael

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

xmlto version 0.0.18

Andreas.

Andreas Schwab venit, vidit, dixit 03.12.2009 14:50:

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

Michael J Gruber wrote:

[...]

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 Zullinger <tmz@pobox.com> writes:

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.

Junio C Hamano wrote:

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?

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 Zullinger <tmz@pobox.com> writes:

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(-)

Junio C Hamano wrote:

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 Zullinger <tmz@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.

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 ;-)

On Thu, Dec 3, 2009 at 5:30 PM, Junio C Hamano <gitster@pobox.com> wrote:

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

Eugene Sajine <euguess@gmail.com> writes:

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).

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

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)

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

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> writes:

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.

Junio C Hamano wrote:

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

Todd Zullinger <tmz@pobox.com> writes:

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.

Todd Zullinger <tmz@pobox.com> writes:

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

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

Junio C Hamano wrote:

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.