What's in git.git (Sep 2008, #02; Wed, 10)

What's in git.git (Sep 2008, #02; Wed, 10)

[Junio C Hamano]

There are still a few topics that are meant for 'maint' cooking in higher
stages; we will have 1.6.0.2 after they are merged down.

On the 'master' front, it looks like 1.6.1 will not have anything
particularly big like 1.6.0 did.  Other than many s/git-foo/git foo/
updates in tests (finished -- the documentation needs to go through the
same process), there are many small bells and whistles enhancements, but
nothing earth shattering.  I am expecting that we will go into 1.6.1-rc0
freeze in two weeks.

* The 'maint' branch has these fixes since the last announcement.

Arjen Laarhoven (1):
  Use compatibility regex library for OSX/Darwin

Junio C Hamano (4):
  checkout: do not check out unmerged higher stages randomly
  diff: Help "less" hide ^M from the output
  log --author/--committer: really match only with name part
  Update draft release notes for 1.6.0.2

Marcus Griep (2):
  Git.pm: Use File::Temp->tempfile instead of ->new
  git-svn: Fixes my() parameter list syntax error in pre-5.8 Perl

Miklos Vajna (1):
  t7501: always use test_cmp instead of diff

Nicolas Pitre (5):
  pack-objects: improve returned information from write_one()
  improve reliability of fixup_pack_header_footer()
  pack-objects: use fixup_pack_header_footer()'s validation mode
  index-pack: use fixup_pack_header_footer()'s validation mode
  fixup_pack_header_footer(): use nicely aligned buffer sizes


* The 'master' branch has these since the last announcement
  in addition to the above.

Alex Riesen (1):
  Add help.autocorrect to enable/disable autocorrecting

Andreas Ericsson (1):
  Teach "git diff -p" to locate PHP class methods

Arjen Laarhoven (1):
  t6023-merge-file: Work around non-portable sed usage

Christian Couder (1):
  refs: improve comments about "reading" argument of "resolve_ref"

Dotan Barak (1):
  Use xmalloc() and friends to catch allocation failures

Eric Wong (1):
  git-svn: fix handling of even funkier branch names

Giovanni Funchal (1):
  configure: auto detect dynamic library path switches

Heikki Orsila (1):
  Start conforming code to "git subcmd" style part 2

Johannes Schindelin (1):
  git wrapper: DWIM mistyped commands

Johannes Sixt (1):
  Windows: git-shell can be compiled again

Junio C Hamano (2):
  Makefile: Allow CC_LD_DYNPATH to be overriden
  Fix git-diff-tree --stdin

Michael J Gruber (2):
  allow installation of man and html doc from the man and html branches
  separate build targets for man and html documentation

Mikael Magnusson (1):
  Correct output of git-count-objects.

Nanako Shiraishi (8):
  t/t91XX-svn: start removing use of "git-" from these tests
  t/t91XX git-svn tests: run "git svn" not "git-svn"
  t9200: use "git cvsexportcommit" without dash
  t9300, t9301: use "git fast-import/fast-export" without dash
  t9700: use "git config" without dash
  tests: use "git foo" without dash in strings
  t9101: use "git hash-object" without dash
  Install git-cvsserver in $(bindir)

Re: What's in git.git (Sep 2008, #02; Wed, 10)

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 11.09.2008 05:49:
> There are still a few topics that are meant for 'maint' cooking in higher
> stages; we will have 1.6.0.2 after they are merged down.
> 
> On the 'master' front, it looks like 1.6.1 will not have anything
> particularly big like 1.6.0 did.  Other than many s/git-foo/git foo/
> updates in tests (finished -- the documentation needs to go through the
> same process), there are many small bells and whistles enhancements, but

Was there some final consensus on how to undashify the man pages? There
is still the issue of keeping man viewers working which detect links
from man page text like git-commit(1). Within a man page context forms
like that are natural and should not be confusing (assuming man users
know man), but for the html version it's unnatural. In fact, even the
section numbers look unnatural on the html version (pretending to be a
non-man-unaware html "customer"); also, the html doc is not split into
subdirs by section.

I think the cleanest approach would consist in introducing another
linkgit macro (for everything linkgit:git-) which ouputs dashed resp.
dashless forms for docbook (i.e. man) resp. html targets. I'll cook up a
POC if noone keeps me from doing so ;)

Michael

P.S.: There are also dashes to be removed in the text (non-link) of the
doc, of course. But this doesn't pose any technical hurdles.

Re: What's in git.git (Sep 2008, #02; Wed, 10)

[Junio C Hamano]

Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:

> I think the cleanest approach would consist in introducing another
> linkgit macro (for everything linkgit:git-) which ouputs dashed resp.
> dashless forms for docbook (i.e. man) resp. html targets. I'll cook up a
> POC if noone keeps me from doing so ;)

I personally think the links are Ok to be left as they are in git-foo form
but if there is a good way to persuade manual viewers to display "git foo"
and still follow "man git-foo", that would be great.

Names of the programs in "git-foo" form in the plain text, unless they are
the server side programs, should be updated to say "git foo"
(cf. http://thread.gmane.org/gmane.comp.version-control.git/95436/focus=95443)