Guilt v0.31 is available for download.

Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.

Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/

Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git


This is a mostly bugfixes-only release to get the fixes that accumulated
over the past several months out of the door.

As always, patches, and other feedback is welcome.

Josef "Jeff" Sipek.

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

Changes since v0.30:

Alan Jenkins (3):
      Better "patch does not exist" checks
      guilt-diff: allow paths
      guilt-diff: behave sanely if no patch applied

Eric Sandeen (1):
      regression: fix failure with Git 1.5.5

Jonas Fonseca (3):
      Documentation: rename guiltlink macro to linkguilt
      Documentation: improve AsciiDoc formatting of lists in guilt(7)
      Documentation: customized the manpage headers to include version info

Josef 'Jeff' Sipek (3):
      Documentation: add proper 'linkguilt's
      patchbomb: fix bashism
      Guilt v0.31

Shawn Starr (1):
      guilt: Fix git version detection on Debian

Theodore Ts'o (2):
      must_commit_first: Make sure the index is up to date
      Make guilt work even after git-sh-setup is moved out of the user's path

-- 
Linux, n.:
  Generous programmers from around the world all join forces to help
  you shoot yourself in the foot for free. 
--

[ message continues ]

Hi,


Is it possible to include pre-generated docs in the tarballs?

I downloaded one and run 'make doc' and get these messages:

fatal: Not a git repository

which looks like it comes from this line in Documentation/Makefile:

VERSION=$(shell git describe)

Its not critical, but looks awkward.

Thanks

Bert
--

[ message continues ]

1) I already commit generated man pages for each release - on the man branch
   (there's also html branch with the html-formated man pages).

2) I'm aware of the git error you saw, and it is on my todo list

3) I just checked the git tarballs, and they don't include man pages either.
   Should I include the manpages in the source tarball, or should I just
   create another tarball with the manpages? (The git error will get fixed
   regardless - that's the only invocation of git during the manpage build
   process, and it's there only to get a nice looking version number to
   include in the manpages.)

Josef 'Jeff' Sipek.

-- 
Bad pun of the week: The formula 1 control computer suffered from a race
condition
--

[ message continues ]

I must admit, that I don't like these extra tarballs with docs. I
always expect, that the manpages are nicely installed if I type 'make
install' (or at least with a install-doc target). But I need to
download this extra package, and extract it to the right place, there
is no Makefile whatsoever. In case of git its really annoying, because
the help mechanism is relying on the manpages (i.e. git help <cmd> or
git <cmd> --help, but you know this).

Thanks
--

[ message continues ]

There is no need to feel "it[']s really annoying", as install-doc from the
tarball distribution works out of the box.

I used 1.6.0.1 in the demonstration below, but this is nothing new in that
version but has been like this for quite some time (it is how sample RPMs
binary packages are built, so the procedure ought to work):

    $ ls -1 /usr/bin/git ;# to show there is no other "git" on this box
    ls: /usr/bin/git: No such file or directory
    $ mkdir /var/tmp/16
    $ cd /var/tmp/16
    $ wget http://www.kernel.org/pub/software/scm/git/git-1.6.0.1.tar.gz
    $ tar xf git-1.6.0.1.tar.gz
    $ cd git-1.6.0.1
    $ make prefix=/var/tmp/16test install install-doc
    $ PATH=/var/tmp/16test/bin:/usr/bin:/bin
    $ export PATH
    $ unset MANPATH
    $ git help cat-file | cat -s | tail -n 8
    Reformatting git-cat-file(1), please wait...
    DOCUMENTATION
           Documentation by David Greaves, Junio C Hamano and the git-list
           <git@vger.kernel.org>.

    GIT
           Part of the git(1) suite

    Git 1.6.0.1                       09/08/2008                   GIT-CAT-FILE(1)


The extra tarballs for documentation are also given as courtesy because
they are supposed to be platform independent and some people do not want
to generate them themselves (even though they could).

Either be thankful for the availability of tarballs, or ignore them and
generate them yourself --- it's your choice.
--

[ message continues ]

This works because you have the full toolchain, especially xmlto.

He might want an install target which installs doc from the doc-tarball
or from the man- and html-branches. Be it a Makefile in those
convenience branches. I know it's just a tar or cpio away, of course. I
might look at a Makefile for the doc branches.

Michael
--

[ message continues ]

Following up on my own mumble: There are some lesser known make targets for git which almost do that already.

make install-html uses only asciidoc and xsltproc, but not xmlto, for generating (and installing) html doc, which makes some people happier already.

make quick-install-doc installs the man pages (and only the man pages, not the html version) by using the "man" branch provided by "the man" (JC).

I would go about renaming quick-install-doc to quick-install-man, introducing quick-install-html doing the analogous using the "html" branch and quick-install-doc doing both, which would be more in line with the install-doc target.

Are there any objections to renaming quick-install-doc to quick-install-man?

Michael
--

[ message continues ]

What does it improve?

IOW, can't you do what you want to do (I am assuming that what you want to
do is to be able to copy out the pregenerated contents from convenience
branches) without such a rename?

If you rename the target, I am reasonably sure you would break somebody's
build procedure.  It is a separate topic if there are large number of such
somebody, or just a limited few.
--

[ message continues ]

It makes it more systematic.

Right now:

Documentation/Makefile:
all: builds html and man
install: installs only man (depends on man)
install-{info,html}: installs $foo (depends on $foo)
quick-install: installs man from man branch

Makefile:
doc: builds html and man (-C D all)
install-doc: installs only man (-C D install)
install-{info,html}: installs $foo (-C D install-$foo)
quick-install-doc: installs man from man branch (-C D install-$foo)

So there is a distinct asymmetry between build targets and install
targets. Wouldn't you expect "make install" to install what "make"
builds? That is true, but "make install-doc" doesn't install what "make
doc" builds.

Put it differently:
doc = man + html for build targets
doc = man for install targets

What's worse: "make doc" fails if you don't have xmlto, even though
"make install-doc" may succeed; but you'll never try it when the build
fails. Until a few hours ago I thought I couldn't build man pages at
work (asciidoc, but no xmlto), and I had never heard about

Sure I can. "Namen sind Schall und Rauch". Names don't matter.
quick-install-html would follow the above logic. I just think that the
doc logic is flawed.

So, my suggestion is that doc = man + html, whether it appears in a

I keep hearing this argument, and I'm even more surprised to hear it
right after a major release. If not now then when's a good time for
cleaning up confusing inconsistencies?

Michael
--

[ message continues ]

Actually, after a major release is the worst time to push for such an
agenda.

Especially when that release burned the maintainer with numerous complains
against a major change in it, that has been advertised for a long time,
which was pushed by other people for no good reason other than "such a
clean-up would make things much tidier".

Grrr ;-).



--

[ message continues ]

For many projects, things become unstable after a major release. This is
the time to experiment. Right before a major release, everything needs
to settle down, with a focus on bugfixes and stability.

That said, I know the "logic" of the make targets now, so I really don't
care any more what they are named. I just meant to keep others from
being confused. So I guess I'll go with the existing naming and fit

Junio,
I think you handled that in the best possible way, and I felt
sympathetic with you when that thread with a RFC went OT back to
discussing things over again.

Cheers,
Michael
--

[ message continues ]