[ANNOUNCE] Guilt v0.31

[ANNOUNCE] Guilt v0.31

[Josef 'Jeff' Sipek]

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. 

Re: [ANNOUNCE] Guilt v0.31

[Josef 'Jeff' Sipek]

On Mon, Sep 08, 2008 at 05:39:20PM +0200, Michael J Gruber wrote:
> Josef 'Jeff' Sipek venit, vidit, dixit 08.09.2008 15:52:
> > 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.
> 
> Guilt insists on being used with git 1.5.*. Is this intended?

Ok, I committed v0.31.1.

Thanks for noticing!

Josef 'Jeff' Sipek.

-- 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.
		- George Bernard Shaw

Re: [ANNOUNCE] Guilt v0.31

[Bert Wesarg]

Hi,

On Mon, Sep 8, 2008 at 15:52, Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:
> Guilt v0.31 is available for download.

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

Re: [ANNOUNCE] Guilt v0.31

[Josef 'Jeff' Sipek]

On Mon, Sep 08, 2008 at 08:33:23PM +0200, Bert Wesarg wrote:
> Hi,
> 
> On Mon, Sep 8, 2008 at 15:52, Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:
> > Guilt v0.31 is available for download.
> 
> 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.

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

Re: [ANNOUNCE] Guilt v0.31

[Bert Wesarg]

On Mon, Sep 8, 2008 at 20:43, Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:
> On Mon, Sep 08, 2008 at 08:33:23PM +0200, Bert Wesarg wrote:
>> Hi,
>>
>> On Mon, Sep 8, 2008 at 15:52, Josef 'Jeff' Sipek <jeffpc@josefsipek.net> wrote:
>> > Guilt v0.31 is available for download.
>>
>> 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.
>
> 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.)
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
Bert
>
> Josef 'Jeff' Sipek.

Re: [ANNOUNCE] Guilt v0.31

[Junio C Hamano]

"Bert Wesarg" <bert.wesarg@googlemail.com> writes:

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

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.

Re: [ANNOUNCE] Guilt v0.31

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 08.09.2008 21:17:
> "Bert Wesarg" <bert.wesarg@googlemail.com> writes:
> 
>> 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).
> 
> 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)
> 

This works because you have the full toolchain, especially xmlto.
asciidoc'ing directly to man (bypassing xmlto) may help some of us.

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

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

Re: [ANNOUNCE] Guilt v0.31

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 09.09.2008 12:10:
> Junio C Hamano venit, vidit, dixit 08.09.2008 21:17:
...
>> Either be thankful for the availability of tarballs, or ignore them and
>> generate them yourself --- it's your choice.
> 
> 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

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

Re: [ANNOUNCE] Guilt v0.31

[Junio C Hamano]

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

> 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?

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.

Re: [ANNOUNCE] Guilt v0.31

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 09.09.2008 17:13:
> Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:
> 
>> 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?
> 
> What does it improve?

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
quick-install-doc until I looked at the Makefiles in detail.

> 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?

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
build target or an install target.

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

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

Re: [ANNOUNCE] Guilt v0.31

[Junio C Hamano]

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

> 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?

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

Re: [ANNOUNCE] Guilt v0.31

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 09.09.2008 18:02:
> Michael J Gruber <michaeljgruber+gmane@fastmail.fm> writes:
> 
>> 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?
> 
> Actually, after a major release is the worst time to push for such an
> agenda.

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
quick-install-html right in. Will go into a new thread tomorrow or so.

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

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