If I call command --help, I don't want a pager barfing at me. Never. I have scrollback for that. It is my choice when I page and when I page not. There are manual pages who go through 50 pages or so, however. There are commands that fundamentally are connected with a pager. man is, for example. But most cases where git calls a pager (and that includes his way of calling man without getting asked for it explicitly) utterly surprise me. So I set GIT_PAGER to cat and hoped that it would get git...

Frequently, git somecommand --help will call the man command to display help pages. I think that when it does so, it should pass the value of the GIT_PAGER variable copied into the PAGER variable: the paging happens on behalf of git here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum -

I currently have GIT_PAGER (actually, core.pager) set to tig. Tig has lots of useful features for visualizing history and jumping between patches and logs. But for everything that isn't git, less is far better. ~~ Brian -

Well, if it were a "pure" manpage, I'd try to use pic(1) to do it for the PS version, but I don't suspect asciidoc has a similar feature. I don't actually know, though -- again, I know virtually nothing about asciidoc. Fredrik Tolf -

I tried with your patch, both with asciidoc7 and asciidoc8. Did you really mean "⌂" above? Replacing them with "." gave me a series of these changes (diff between output before and after your patch with the "s/\⌂/./g" fixup): @@ -83,10 +83,13 @@ .sp .RS 3n .nf +.ft C *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: q...

For the html output we can use a stylesheet to make sure that the listingblocks are presented in a monospaced font. For the manpages do it manually by inserting a ".ft C" before and ".ft" after the block in question. This makes the ascii-art diagrams readable in PS output. In order for these roff commands to get through to the manpage they have to be element encoded to prevent quoting. In particular with docbook xsl 1.72.0 and newer we have to use U+2302 instead of . to prevent the roff command ...

2007/7/18, Kristian H

I often read manpages using a `man -t whatever | ggv -' command, since I like how it is rendered in PostScript. However, it turns out that some things in the Git manpages don't really render very well using that method. For example, in the git-rebase manpage, there are two history graphs that look like this when reading the manpages normally in a terminal: A---B---C topic / D---E---F---G master and then A'--B'--C' topic / D---E---F---G master Howeve...

[perrin@whisper TESTGIT]$ git svn --version git-svn version 1.5.3.rc2.4.g726f9 (svn 1.2.3) I get the "post commit" email from our SVN central server, so it appears that on the SVN side the commit worked? I tried running git svn with --verbose, but that did not print out any more error messages (besides the seg fault). Thanks, Perrin ----- Original Message ---- From: Eric Wong <eric@petta-tech.com> To: Perrin Meyer <perrinmeyer@yahoo.com> Cc: git@vger.kernel.org Sent: W...

The only thing that's totally missing at this point from my builtin-fetch is rsync. Do we still care? Any takers for actually implementing it? -Daniel *This .sig left intentionally blank* -

Maybe pull the rsync parts from the old fetch, put them into a script and call it? Not very simple, as it looks. Maybe not worth the effort. -

By sourcing git-filter-branch and stopping after the function definitions, the commit filter can now access the convenience functions like "map". This is done automatically if you specify a commit filter. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- git-filter-branch.sh | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/git-filter-branch.sh b/git-filter-branch.sh index 0d000ed..b574612 100755 --- a/git-filter-branch.sh +++ b/git...

By sourcing git-filter-branch and stopping after the function definitions, the commit filter can now access the convenience functions like "map". Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> --- On Wed, 18 Jul 2007, Junio C Hamano wrote: > Exporting this_script variable, and changing the above to > > filter_commit='SOURCE_FUNCTIONS=1 . "$this_script";'" $OPTARG" > > to arrange the shell that is invoked with 'sh -c' to expand its > value...

Hi, My timezone is set to right/Europe/Berlin. git-log 1.5.2.2 gives me output such as: | Date: Wed Jul 18 16:17:31 2007 +0159 Note the timezone, which should be +0200. I'm using tzcode/tzdata 2007f from <ftp://elsie.nci.nih.gov/pub/>. A small test script is attached. Regards, Peter Hartlich

No, I do not think the wackiness is from Germans. Using right/ perhaps without realizing the differences between TZ=right/Europe/Berlin and TZ=Europe/Berlin is probably the source of confusion. I do not offhand know what role "leap second adjustment" should play in the context of converting from Unix time we store in git commit objects to human readable role. As far as I understand, the returned timestamp from time(2), which we record in commit objects, is already "leap second adjusted". ...

Well ... not if you compare right/Europe/Berlin vs right/CET jp3@neutron: ~>TZ=right/CET date '+%H:%M:%S %z'; TZ=right/Europe/Berlin date '+%H:%M:%S %z' 19:49:45 +0200 19:49:45 +0200 but, I suspect that the following is the underlying cause of the problem? jp3@neutron: ~>TZ=right/UTC date '+%H:%M:%S %z'; TZ=UTC date '+%H:%M:%S %z' 17:51:32 +0000 17:51:55 +0000 Is git working internally in TZ=UTC? -- Julian --- Homer: We always have one good kid and one lousy kid. Wh...

Forgot to add that the bug is present in the current dev version. Regards, Peter Hartlich -

Thanks, pulled (but not pushed out yet). -

Some people might prefer to be able to specify the find utility to use, in particular for the more complicated usage in the install-symlinks target. Signed-off-by: David Kastrup <dak@gnu.org> --- Makefile | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 7e53378..cf72327 100644 --- a/Makefile +++ b/Makefile @@ -178,6 +178,7 @@ AR = ar RM = rm -f TAR = tar INSTALL = install +FIND = find RPMBUILD = rpmbuild TCL_PATH...

Not in bash. Just tried it. But there are Bourne shells that do get I'd rather write [ "X$CDPATH" = "X" ] || unset CDPATH With regard to shells, there is an interesting document (info "(autoconf) Portable Shell") which is rather disillusioning. A real horror show is (info "(autoconf) Limitations of Builtins") where one learns that using if without else can lead to bad exit status, too. -- David Kastrup -

Oh, by the way: I got _crazy_ when I first committed this, then found a mistake and corrected it, and then repeatedly did git add config/emacs/Makefile git-commit --amend message again and again, while nothing at all changed. Of course, this was because I added the wrong Makefile. I am not sure how git could be more helpful here. Just wanted to report it. Maybe it could have noticed that my "amendment" was empty? On the other hand, I might have wanted to amend the commit message. Sigh. ...

Sometime about now you'll need to define $(FIND) or even $(GNUFIND) for find. There are proprietary systems where find is not available or does not do what you want it to. There is often a gfind installed somewhere on these systems. -

Seeing this excellent explantion from Dscho, this sound exactly like a perfect use case for xstow [1]. It allows you to install your application into e.g. /usr/local/stow/git and by running 'xstow git' in /usr/local/stow it would create all the necessary links in /usr/local/{bin,share,doc} or any other place you want. -Peter [1]: http://xstow.sourceforge.net/ -

Hi, No, no, no. It should not be tracked. It is the responsibility of the _user_ to set it to something sane, be that by a umask or by sticky groups, or by setting the permissions of the parent directory. It is _nothing_ we want to put into the repository. That is the _wrong_ This question is invalid. Git only tracks the _executable_ bit. And again, it is the users' responsibility, by setting the umask, to have the I have. But that does not apply here, because I used the term "...

Passing of ce instead of path in the unpack-trees callchain looks like the right thing to do. Good job. Thanks. -