* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 16:04 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46B4A2B0.9080208@gmail.com>
Hi,
On Sat, 4 Aug 2007, Mark Levedahl wrote:
> git>git bisect good
Could you please
GIT_TRACE=1 make quick-install-doc
? It breaks here, too, but because I have no origin/man branch.
Ciao,
Dscho
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Mark Levedahl @ 2007-08-04 16:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708041704040.14781@racer.site>
Johannes Schindelin wrote:
>
> Could you please
>
> GIT_TRACE=1 make quick-install-doc
>
> ? It breaks here, too, but because I have no origin/man branch.
>
> Ciao,
> Dscho
>
>
>
git>GIT_TRACE=1 make prefix=/usr quick-install-doc
make -C Documentation quick-install
make[1]: Entering directory `/usr/src/git/Documentation'
make -C ../ GIT-VERSION-FILE
make[2]: Entering directory `/usr/src/git'
make[2]: `GIT-VERSION-FILE' is up to date.
make[2]: Leaving directory `/usr/src/git'
sh ./install-doc-quick.sh origin/man /usr/share/man
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--verify' 'origin/man^0'
trace: built-in: git 'read-tree' 'origin/man'
trace: built-in: git 'checkout-index' '-a' '-f' '--prefix=/usr/share/man/'
make[1]: Leaving directory `/usr/src/git/Documentation'
git>man git
No manual entry for git
git>
Mark
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Mark Levedahl @ 2007-08-04 16:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708041715140.14781@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 4 Aug 2007, Mark Levedahl wrote:
>
>
>> git checkout-index -a -f --prefix="$mandir"/
>>
>
> Just to hazard a guess... you see an error message there, such as "cannot
> chdir to <blablabla>: No such file or directory"?
>
> It's kinda hard to debug this with incomplete information.
>
> Ciao,
> Dscho
>
>
>
Nope - no error messages, nada. The trace output I sent you is
absolutely uninformative as well. There is absolutely no visible
difference between the version where this works (the previous commit)
and the version where it does not, except that in the latter case the
files are not written out (or at least not to where they should be
written nor to any other place I can find.
If you have any suggestions on how I can help debug this, I am more than
willing but not at all familiar with the internal workings of git.
Mark
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-04 16:27 UTC (permalink / raw)
To: Steven Grimm; +Cc: Sam Ravnborg, Junio C Hamano, Ismail Dönmez, git
In-Reply-To: <46B4A35E.5040601@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> David Kastrup wrote:
>> A system such as info, in contrast, is hierarchical, and organized
>> with indexes and cross references making it much easier to find
>> things.
>
> Really? I find info a huge pain in the butt most of the time.
> I can't just do a simple text search for the information I want in
> the relevant manpage; I have to go navigating around to the
> appropriate subsection (and that's assuming I know where it is)
You are presumably talking about the standalone reader. I never use
it, so can't really say much about it. With Emacs, you just do C-s
and search. Hitting C-s again will extend the search to the section,
and then to the whole file.
> and am forced to use the emacs-style pager whether I like it or not
> (not a big emacs fan here). It always ticks me off when I go to read
> the manpage for some command and it tells me to go read the info
> page if I want complete documentation.
>
> I would definitely not want to move to a documentation system that
> prevented me from typing "man git-commit" to get a list of all the
> command line options for that command.
Nobody said that we would want to get rid of man pages.
Anyway, with the info reader, you should at worst use something like
info git
i git-commit RET
to get to the git-commit man page equivalent.
> However, that said, I have no objection to an alternate view of the
> same information that's organized differently.
>
> Am I alone in my dislike of info, I wonder?
I don't use the standalone info reader. It is likely quite less
sophisticated and convenient than what Emacs does with info files.
The few times I have used it, I felt inconvenienced IIRC, though it
has supposedly been improved some time ago after being left in the
lurch for quite long. But actually you can also use yelp to browse
info pages (point it at, say, info:coreutils).
So I would definitely agree with your assessment that _replacing_ the
man pages by info would not be the right way to go. However, nobody
asked for that. The idea was to use _Texinfo_, and this produces
plain text, HTML, info files, quite nice PDF and some other formats.
Of _course_, we want to have man pages as well. I pointed out a
reference to the GCC project where they explain how they generate man
pages from Texinfo. One would have to check whether this can be
applied to the git pages, of course.
There was also the question how to integrate documentation into
something like gitk, and there is a Tkinfo widget that could
conceivably be used. Texinfo files can also be converted into flat
text files with basic markup (and man pages don't give you more than
that, anyway).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 16:21 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46B4A5FD.3070107@gmail.com>
Hi,
On Sat, 4 Aug 2007, Mark Levedahl wrote:
> Johannes Schindelin wrote:
> >
> > Could you please
> >
> > GIT_TRACE=1 make quick-install-doc
> >
> > ? It breaks here, too, but because I have no origin/man branch.
> >
> > Ciao,
> > Dscho
> >
> >
> >
> git>GIT_TRACE=1 make prefix=/usr quick-install-doc
> make -C Documentation quick-install
> make[1]: Entering directory `/usr/src/git/Documentation'
> make -C ../ GIT-VERSION-FILE
> make[2]: Entering directory `/usr/src/git'
> make[2]: `GIT-VERSION-FILE' is up to date.
> make[2]: Leaving directory `/usr/src/git'
> sh ./install-doc-quick.sh origin/man /usr/share/man
> trace: built-in: git 'rev-parse' '--git-dir'
> trace: built-in: git 'rev-parse' '--verify' 'origin/man^0'
> trace: built-in: git 'read-tree' 'origin/man'
> trace: built-in: git 'checkout-index' '-a' '-f' '--prefix=/usr/share/man/'
> make[1]: Leaving directory `/usr/src/git/Documentation'
At this point, could you try debugging it? For example, set a break point
in set_work_tree(), since that is the only function that commit touches,
and see what it returns both before and after the bad commit?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Linus Torvalds @ 2007-08-04 16:37 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, V?in? J?rvel?, git
In-Reply-To: <20070804071131.GA6557@coredump.intra.peff.net>
On Sat, 4 Aug 2007, Jeff King wrote:
>
> On Sat, Aug 04, 2007 at 02:55:16AM -0400, Shawn O. Pearce wrote:
>
> > V??in?? J??rvel?? <v@pp.inet.fi> wrote:
>
> Your mailer claims this message is in us-ascii, but I think it isn't...
Actually, the email claims it was iso-latin1, at least here. Which the
*body* of the email apparently really was.
However (and this is a pretty common thing), the *headers* are
unspecified, and a lot of email clients seem to think that if that
happens, they default to US-ASCII and think that those iso-latin1
characters are crud.
Which is a damn shame. "alpine" does this, and it irritates me no end. I
see emails where I can read the body fine, but it shows '????' for subject
lines and authors even though it's the exact same character set.
Stupid, stupid, stupid.
Dammit, if the thing says
Content-type: text/plain; charset=ISO-8859-1; format=flowed
(which it did), then yes, by some idiotic reading of the RFC's that
probably only affects the body of the email. But those headers (and the
"From:" line in particular) were *also* in ISO-8859-1, and email clients
should default to using the same character set unless something else is
said.
Btw, I suspect git "mailsplit" gets this wrong too. I rant and rave, but
in the end, I solved it by just having the code guess sanely (commit
b59d398beab604e577846ef8393735478c1ca3c2 makes things come out right in
practice, regardless) instead of trying to do something "technically
correct".
Linus
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Johannes Schindelin @ 2007-08-04 16:16 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46B4A47E.5030901@gmail.com>
Hi,
On Sat, 4 Aug 2007, Mark Levedahl wrote:
> git checkout-index -a -f --prefix="$mandir"/
Just to hazard a guess... you see an error message there, such as "cannot
chdir to <blablabla>: No such file or directory"?
It's kinda hard to debug this with incomplete information.
Ciao,
Dscho
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 17:00 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff King, git
In-Reply-To: <8c5c35580708040607ya186edcg89fbc90587b64d68@mail.gmail.com>
"Lars Hjemli" <lh@elementstorage.no> writes:
> The magic setup that makes this happen is the following lines in .git/config:
>
> [remote "origin"]
> url = git://git.kernel.org/pub/scm/git/git.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
>
> Was this helpful?
It would be helpful. Except that nothing whatsoever can be found in
.git/config concerning my local and my remote tracking branches. So
where is that information _really_ hidden away?
.git/FETCH_HEAD maybe?
It also appears that doing
git-checkout --track -b mybranch origin
on a git.git clone does _not_ create a tracking branch. I can't
figure out what I could specify as an origin to create a tracking
branch that would get reflected in .git/FETCH_HEAD.
What gives?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Linus Torvalds @ 2007-08-04 16:59 UTC (permalink / raw)
To: David Kastrup
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85zm17h4pn.fsf@lola.goethe.zz>
On Sat, 4 Aug 2007, David Kastrup wrote:
>
> A system such as info, in contrast, is hierarchical, and organized
> with indexes and cross references making it much easier to find
> things.
You must be kidding. Texinfo is the worst documentation format EVER. And
the readers universally suck too, unless you're a total GNU emacs fan and
have been for a decade, and have problems understanding people who don't
like the all-in-one mentality.
There are absolutely _zero_ advantages in Texinfo over AsciiDoc. It has
all the same disadvantages, except the source files are *also* unreadable
(which is the one really nice feature of AsciiDoc - you can ignore
everything else, and just read the original .txt file).
Linus
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Julian Phillips @ 2007-08-04 17:19 UTC (permalink / raw)
To: David Kastrup; +Cc: Lars Hjemli, Jeff King, git
In-Reply-To: <85r6mjdyl8.fsf@lola.goethe.zz>
On Sat, 4 Aug 2007, David Kastrup wrote:
> "Lars Hjemli" <lh@elementstorage.no> writes:
>
>> The magic setup that makes this happen is the following lines in .git/config:
>>
>> [remote "origin"]
>> url = git://git.kernel.org/pub/scm/git/git.git
>> fetch = +refs/heads/*:refs/remotes/origin/*
>>
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>>
>>
>> Was this helpful?
>
> It would be helpful. Except that nothing whatsoever can be found in
> .git/config concerning my local and my remote tracking branches. So
> where is that information _really_ hidden away?
It really is in .git/config, _provided_ that your repo was created by
1.5.0 or newer. Older versions had a more distributed setup using files
in .git/remotes/ and .git/branches/
> .git/FETCH_HEAD maybe?
Nope, that's just information about what got fetched last. A purely
temporary thing.
> It also appears that doing
>
> git-checkout --track -b mybranch origin
>
> on a git.git clone does _not_ create a tracking branch. I can't
> figure out what I could specify as an origin to create a tracking
> branch that would get reflected in .git/FETCH_HEAD.
With pre 1.5 you didn't get remote tracking branches in a separate
namespace. The default was to have a local branch called origin which was
the "remote tracking branch" for the master branch - but this wasn't
enforced. So with your repo the origin branch _is_ the remote tracking
branch ... or at least the closet a pre 1.5 setup gets.
> What gives?
It would appear that your repo was created with an old version of git.
Which also explains why you were talking about origin as a branch - which
it used to be (a real local branch too ...), rather than as a remote -
which it is now.
The whole remotes/tracking mechanism changed in 1.5.0 - now it's much more
flexible (and probably more complicated too).
--
Julian
---
Ever notice that even the busiest people are never too busy to tell you
just how busy they are?
^ permalink raw reply
* gitbox status (for those who want to hack on it)
From: Nguyen Thai Ngoc Duy @ 2007-08-04 17:40 UTC (permalink / raw)
To: Git Mailing List; +Cc: Mike Pape, Paul Hampson
I would say it's in pretty good state now because it can run through
test cases. Running tests on Windows can take about an hour so I'll
put test results here so you don't have to rerun the whole thing if
you want to know what part needs work. Known failed tests:
t1301-shared-repo.sh: no umask on gitbox
t3200-branch.sh: "unable to move logfile" and "Not a valid object name"
t3405-rebase-malformed.sh: no idea
t3900-i18n-commit.sh: failed due to diff not ignore \r. I don't really
care about this.
t3902-quoted.sh: both gitbox and the official branch fail on this,
haven't looked at it
t4020-diff-external.sh: "unable to fork", diff external programs
should be run under sh
t4110-apply-scan.sh: bad busybox patch, no cure
t4114-apply-typechange.sh: ln
t5000-tar-tree.sh: needs /bin/sh. Even if /bin/sh existed, still
failed for some reasons. This test passed under Wine
t5300-pack-object.sh: busybox ash does not understand "read -d", any workaround?
t5302-pack-index.sh: dd
t5502-quickfetch.sh: git-remote is a perl script. this test itself
also requires perl
t6002-rev-list-bisect.sh: worked under wine but failed under xp, dunno why
t7003-filter-branch.sh: git-filter-branch does not understand Windows
absolute path, among others
t7005-editor.sh: vi is needed
t7300-clean.sh: no idea, ran fine under wine
t7500-commit.sh: probably because busybox diff can't diff on
non-seekable input like stdin
t7501-commit.sh: failed on interactive add, no idea
t8001-annotate.sh: needs perl
t8002-blame.sh: needs perl
t9001-send-email.sh: well git-send-email is written in perl so...
Tests were run on commit f04fbf244970358a5c9d621c99b2353aecb34a12 with
arguments --no-symlinks --verbose
gitbox also grows its toolkit a bit. The complete list is:
[, [[, ash, awk, basename, bunzip2, bzcat, cat, chmod,
cmp, cp, cut, date, diff, dirname, echo, egrep, env, expr,
false, fgrep, find, grep, gunzip, gzip, head, ls, md5sum,
mkdir, mv, od, patch, printenv, printf, pwd, realpath,
rm, rmdir, sed, seq, sh, sleep, sort, sum, tail, tar,
test, touch, tr, true, uniq, unzip, wc, which, yes, zcat
patch is not really good. ls is a hacked version, made for tests only.
tar does not support verbose mode. diff does not support non-seekable
input. The rest should work fine.
--
Duy
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Junio C Hamano @ 2007-08-04 17:48 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20070804160409.GA16326@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Aug 04, 2007 at 04:36:59PM +0100, Johannes Schindelin wrote:
>
>> > $ git-clone foo bar
>> > Initialized empty Git repository in ...
>> > 0 blocks
>>
>> According to http://www.opengroup.org/onlinepubs/7990989775/xcu/cpio.html,
>> cpio does not know about --quiet. I think this is another GNUism...
>
> Ugh, I didn't even think to check the spec, thanks for looking (I should
> have been tipped off by the presence only of a long option).
>
> I'm not sure what the best solution is...adding --quiet makes it totally
> unportable, but that message almost looks like an error. We can redirect
> stderr, but then we potentially miss real errors.
I was hoping that we can say that the output is analogous to the
native transport reporting "Conting objects: XXXX" and stuff...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-04 17:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <alpine.LFD.0.999.0708040954320.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 4 Aug 2007, David Kastrup wrote:
>>
>> A system such as info, in contrast, is hierarchical, and organized
>> with indexes and cross references making it much easier to find
>> things.
>
> You must be kidding. Texinfo is the worst documentation format EVER.
Oh come on. It was the first hyperlinked and hierarchical format
before HTML even existed. Its age shows, but the replacements have
not managed to produce anything more useful. There have been
discussions about replacing the _info_ format with an HTML or XHTML
subset, however, that conveys the same amount of hierarchical
information.
> And the readers universally suck too, unless you're a total GNU
> emacs fan and have been for a decade, and have problems
> understanding people who don't like the all-in-one mentality.
Actually, a decade ago the Emacs-internal info reader was worse than
it is now.
Any, after you have in your usual amicable manner declared anybody
insane that would not use the same tools as you, let us come back to
the plain facts again.
> There are absolutely _zero_ advantages in Texinfo over AsciiDoc.
There are, of course, advantages to Texinfo. Any system that is not
completely braindead has some unique advantages, and not everything
not designed by you is braindead.
One advantage to Texinfo is that it is _structured_: whether or not
you like the available info readers, there is the information "up",
"next", "previous" in every node, and every node has a hyperlinkable
name which you can use for referring to it. And the info readers are
aware of that, and you can navigate using single keystrokes.
Now it may well be possible to put the same information into AsciiDoc
files, but there are no _readers_, bad or not, that would make use of
it.
I can specify something like
(info "(gcc) Extended Asm")
and when you are reading mail in Emacs, you can click on that line and
get to the respective page in a manual comprising hundreds of pages.
You can, of course, also type
info "(gcc) Extended Asm"
into your command line and use the standalone info reader to get
immediately to that line.
You can also get there by typing
info gcc
i assem <TAB>
and picking the right of three choices from the index. The standalone
reader may not be pretty, but it does the job of accessing those
informations, and you can with single keypresses go up and forward in
a hierarchically organized, _structured_ manual of hundreds of pages.
And as opposed to AsciiDoc, there _are_ readers that make use of this
information.
> It has all the same disadvantages, except the source files are
> *also* unreadable (which is the one really nice feature of AsciiDoc
> - you can ignore everything else, and just read the original .txt
> file).
So what?
makeinfo --plaintext
exists. The important thing for a source file format is that it is
_writeable_. Restricting a source file format to carry just that kind
of information which can be made to look pretty is a mistake in my
book.
Anyway, here are some sections from AUCTeX's README generated from
readme.texi:
Introduction to AUCTeX
**********************
This file gives a brief overview of what AUCTeX is. It is *not* an
attempt to document AUCTeX. Real documentation for AUCTeX is available
in the manual, which should be available as an info file after
installation.
1 Installation
**************
Read the `INSTALL' or `INSTALL.windows' file respectively for
comprehensive information about how to install AUCTeX.
The installation routine tries to make the modes provided by AUCTeX
the default for all supported file types. If this does not happen in
your case, add
(load "auctex.el" nil t t)
to your init file and consult the section about loading the package
in the `INSTALL' file.
If you want to change the modes for which it is operative instead of
the default, use
M-x customize-variable RET TeX-modes RET
If you want to remove a preinstalled AUCTeX completely before any of
its modes have been used,
(unload-feature 'tex-site)
should accomplish that.
If you are considering upgrading AUCTeX, the recent changes are
described in the `CHANGES' file.
Actually, the indentation could be prettier if the quote environments
were properly set off as paragraphs.
Anyway, here is the corresponding source (it suffers from the
complications that it is the start of the file, and that the README
can be produced both as a top-level standalone file, as well as a
subordinate chapter in the containing complete documentation).
@include macros.texi
@ifset rawfile
@chapheading Introduction to @AUCTeX{}
@raisesections
@end ifset
@ifclear rawfile
@node Introduction, Installation, Copying, top
@chapter Introduction to @AUCTeX{}
@end ifclear
@ifset rawfile
This file
@end ifset
@ifclear rawfile
This section of the @AUCTeX{} manual
@end ifclear
gives a brief overview of what @AUCTeX{} is. It is @strong{not} an
attempt to document @AUCTeX{}. Real documentation for @AUCTeX{} is
available in the
@ifset rawfile
manual, which should be available as an info file after installation.
@end ifset
@ifclear rawfile
rest of the manual.
@end ifclear
@section Installation
Read the
@ifset rawfile
@file{INSTALL} or @file{INSTALL.windows} file
@end ifset
@ifclear rawfile
section @ref{Installation}, or @ref{Installation under MS Windows},
@end ifclear
respectively for comprehensive information about how to install
@AUCTeX{}.
The installation routine tries to make the modes provided by @AUCTeX{}
the default for all supported file types. If this does not happen in
your case, add
@lisp
(load "auctex.el" nil t t)
@end lisp
to your init file and consult the section
@ifset rawfile
about loading the package in the @file{INSTALL} file.
@end ifset
@ifclear rawfile
@ref{Loading the package}.
@end ifclear
If you want to change the modes for which it is operative instead of the
default, use
@example
@kbd{M-x customize-variable RET TeX-modes RET}
@end example
If you want to remove a preinstalled @AUCTeX{} completely before any of
its modes have been used,
@example
(unload-feature 'tex-site)
@end example
should accomplish that.
If you are considering upgrading @AUCTeX{}, the recent changes are
described in
@ifset rawfile
the @file{CHANGES} file.
@end ifset
@ifclear rawfile
@ref{Changes}.
@end ifclear
This is reasonable writeable, and it contains all the information for
hyperlinking and cross-referencing the stuff. It is not necessarily
overly pretty, but it can be converted very efficiently both into
single file PDF which can be either navigated on its own or printed,
or into raw text files similar to the existing documentation, or into
HTML or into info, for which efficient _hierarchical_ readers exist.
Now XML certainly has all the expressivity needed to represent the
same information, but you still need a reader that actually makes use
of it. And you have to have the information also expressed in
AsciiDoc, and the requirement that it still looks good in the _source_
code makes it awkward designing an appropriate ASCII way of
representing the information.
AsciiDoc may have the _potential_ to do the same, but at the current
point of time, I don't see that there are tools for conveniently
navigating hundred-page and longer AsciiDoc documents. And there are
for Texinfo.
I am fine if you don't like Texinfo and would rather use something
different with the _same_ amount of information content as Texinfo
has, and with readers that make use of it. Heck, _if_ the source
format can be made to represent the same information, it might be
possible to create Texinfo or at least info pages from it.
Texinfo is not really the point. It is just there to show that it
_is_ possible to work with documentation that provides a _structured_
view into a _large_, coherent document. Of course, by far the best
reader for it (or rather the generated info files) is Emacs, and
that's definitely a drawback for those who don't work with it. The
standalone reader has been sub-par for decades. At the current point
of time, it may be considered tolerable, but not exciting. But at
least it exists.
Man pages don't scale to hundreds of pages, and neither does the
current organization of git documentation do this. If you can propose
something that works at least as well as Texinfo for navigating
hundreds of pages of information, go ahead.
It is not that Texinfo is great. It is just that I don't see an
alternative that sucks less right now. Lots of _formats_ would have
potential for it, but the readers for making use of such documentation
are just not there. And PDF is not really a good alternative, since
fonts, pagination and linear order are not optimized for screen, but
for print. And of course, it is much slower to display, and has no
up/down navigation, but only forward/back.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Jeff King @ 2007-08-04 17:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, V?in? J?rvel?, git
In-Reply-To: <alpine.LFD.0.999.0708040928350.5037@woody.linux-foundation.org>
On Sat, Aug 04, 2007 at 09:37:17AM -0700, Linus Torvalds wrote:
> > Your mailer claims this message is in us-ascii, but I think it isn't...
>
> Actually, the email claims it was iso-latin1, at least here. Which the
> *body* of the email apparently really was.
I think something is munging along the way for at least one of us. My
copy of the mail clearly says:
Content-type: text/plain; charset=us-ascii
and it has been through nothing between vger and my disk except qmail
(and there tends to be no munging there, since qmail accepts 8bit smtp).
The "from" header, on the other hand, is encoded in rfc2047-style
iso-8859-1.
-Peff
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Jeff King @ 2007-08-04 17:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwswbgphu.fsf@assigned-by-dhcp.cox.net>
On Sat, Aug 04, 2007 at 10:48:29AM -0700, Junio C Hamano wrote:
> I was hoping that we can say that the output is analogous to the
> native transport reporting "Conting objects: XXXX" and stuff...
It always says "0 blocks" for me, which looks a bit like an error (but
the clone seems to work fine).
-Peff
^ permalink raw reply
* Re: rc4 - make quick-install-doc is broken
From: Mark Levedahl @ 2007-08-04 17:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708041719490.14781@racer.site>
Johannes Schindelin wrote:
> At this point, could you try debugging it? For example, set a break point
> in set_work_tree(), since that is the only function that commit touches,
> and see what it returns both before and after the bad commit?
>
> Ciao,
> Dscho
>
>
>
Before the bad commit, set_work_tree returns (null), and
variable dir_buffer in the call to get_relative_cwd is
"/usr/src/git/.git/HEAD"
After, it returns "Documentation/", and
variable dir_buffer in the call to get_relative_cwd is "/usr/src/git"
I do not understand what the desired changes in this patch were so am
really lost as to what should be fixed. However, the above I hope will
give you a good clue as to what is broken.
Mark
^ permalink raw reply
* Re: [PATCH] git-gui: Added support for OS X right click
From: Jeff King @ 2007-08-04 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, V?in? J?rvel?, git
In-Reply-To: <alpine.LFD.0.999.0708040928350.5037@woody.linux-foundation.org>
On Sat, Aug 04, 2007 at 09:37:17AM -0700, Linus Torvalds wrote:
> However (and this is a pretty common thing), the *headers* are
> unspecified, and a lot of email clients seem to think that if that
> happens, they default to US-ASCII and think that those iso-latin1
> characters are crud.
Well, that _is_ what the standard says, I believe. I agree with you that
practice is more important than a standard, and if there are high-bit
characters in the 'From' field, I think that using the body charset is a
reasonable guess (although keep in mind that the "body" could be hidden
below a multipart/mixed, multipart/alternative, or some other arcane
structure).
But I really have no idea why fully mime-aware mailers refuse to use
rfc2047 encoding of the headers. In fact, my copy of the message you
sent (to which I am replying) has munged Väinö's name in the cc header,
because it failed to use rfc2047 encoding. I'm surprised that alpine
would fail to get that right.
-Peff
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-04 18:00 UTC (permalink / raw)
To: Julian Phillips; +Cc: Lars Hjemli, Jeff King, git
In-Reply-To: <Pine.LNX.4.64.0708041804260.13596@beast.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Sat, 4 Aug 2007, David Kastrup wrote:
>
>> "Lars Hjemli" <lh@elementstorage.no> writes:
>>
>>> The magic setup that makes this happen is the following lines in .git/config:
>> It would be helpful. Except that nothing whatsoever can be found in
>> .git/config concerning my local and my remote tracking branches. So
>> where is that information _really_ hidden away?
>
>> What gives?
>
> It would appear that your repo was created with an old version of
> git. Which also explains why you were talking about origin as a
> branch - which it used to be (a real local branch too ...), rather
> than as a remote - which it is now.
>
> The whole remotes/tracking mechanism changed in 1.5.0 - now it's
> much more flexible (and probably more complicated too).
I think I am going to cry. So I need to rebase my branches, pull out
the resulting patch sets, scrap my repository, clone it new from
upstream, reapply my branches, in order to have a system where the
documentation is somewhat in synch with the actual behavior?
[...]
No, it would seem that I can just
git-clone -l
my repository and be set up in the new order of things. Nice.
However, it would appear from my experiments up to now that the
--track option _can't_ be made to work with a 1.4 repository. I think
that is worth mentioning in the docs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Junio C Hamano @ 2007-08-04 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20070804175240.GB17113@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Aug 04, 2007 at 10:48:29AM -0700, Junio C Hamano wrote:
>
>> I was hoping that we can say that the output is analogous to the
>> native transport reporting "Conting objects: XXXX" and stuff...
>
> It always says "0 blocks" for me, which looks a bit like an error (but
> the clone seems to work fine).
Try cloning across filesystem boundaries so that you do not get
a hardlink -- you will get block count of the copy ;-)
^ permalink raw reply
* Re: [RFC/PATCH] update-index: Add a --refresh-only option to refresh specified files.
From: Junio C Hamano @ 2007-08-04 18:34 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87odhnk4cb.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> This allows to quickly refresh a file that has been touched without
> having to stat all the files of the project.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
> ---
>
> Does this look reasonable? The refresh_index_path() function is a
> copy/paste of refresh_index(), I'm not sure all of it is really
> needed, but I don't claim to understand all the subtleties of the
> index management...
Makes me wonder why it is not like:
$ git update-index --refresh Documentation/
That is:
- why a new option?
- why not a pathspec or glob, similar to what ls-files gets?
^ permalink raw reply
* Re: git-gui console app ?
From: Junio C Hamano @ 2007-08-04 18:38 UTC (permalink / raw)
To: Erik Colson; +Cc: git
In-Reply-To: <20070804123834.GA3036@Mac2.local>
Erik Colson <eco@ecocode.net> writes:
> On Sat, Aug 04, 2007 at 08:03:42AM -0400, Jeff King wrote:
>> On Sat, Aug 04, 2007 at 01:53:31PM +0200, Erik Colson wrote:
>>
>> > Thanks for the very fast answer. I'm currently trying it out. However
>> > I can't figure out how to view the 'changed but not updated' in diff
>> > format...
>>
>> git-diff ?
>>
>> By default, it will show the changes between your working tree and the
>> index (i.e., changed but not updated). You can show the diff of "updated
>> but not commited" with "git-diff --cached".
>
> Peff,
>
> yep that is the info I would like to browse in a way git-gui does it...
> showing a list of the files in the diff, and letting the user select a
> file to show the part of the diff for that file.
Since you are an Emacs user, perhaps contrib/emacs/* would be
more to your taste?
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Linus Torvalds @ 2007-08-04 19:03 UTC (permalink / raw)
To: David Kastrup
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <85myx7dwb3.fsf@lola.goethe.zz>
On Sat, 4 Aug 2007, David Kastrup wrote:
> >
> > You must be kidding. Texinfo is the worst documentation format EVER.
>
> Oh come on. It was the first hyperlinked and hierarchical format
> before HTML even existed.
Yes. And it should have died after html took its place.
> Actually, a decade ago the Emacs-internal info reader was worse than
> it is now.
Wow. I've used the emacs one, and the stand-alone info one, and both are
pretty horrid. You're saying that they used to be _worse_?
(Admittedly, my GNU emacs-fu is very weak. I use an emacs-like editor, but
it's just an editor, and it's subtly different, so I actually find the
"real" emacs to be really disturbing on so many levels ;)
> [ structure ]
>
> And as opposed to AsciiDoc, there _are_ readers that make use of this
> information.
None that any normal user would want to use.
The thing is, html does a much better job of all of that, simply because
there are useful readers. The same, btw, goes for man-pages: even though
they have no structure at all, just the fact that normal people know how
to use them, they are actually superior to info pages!
That's something that the FSF seems to have missed in their push for info
format: a lot of FSF programs have really substandard man-pages, but that
doesn't mean that people read the info ones _anyway_. Because the readers
are so disgustingly horrible, plain man-pages are actually much more
useful, despite the fact that they don't have any cross-referencing etc.
Linus
^ permalink raw reply
* possible bug in git apply?
From: david @ 2007-08-04 19:45 UTC (permalink / raw)
To: git; +Cc: rob
since git doesn't track directories, only content (per the big discussion
recently) I beleive that doing a checkout would leave Rob without the
directories that he emptied out, so shouldn't git apply also clear the
directories to end up in the same state?
David Lang
---------- Forwarded message ----------
Date: Sat, 4 Aug 2007 15:19:54 -0400
From: Rob Landley <rob@landley.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roland Dreier <rdreier@cisco.com>,
Linux Kernel <linux-kernel@vger.kernel.org>, linux-doc@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>, Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH 1/2] Group architecture Documentation under
Documentation/arch.
On Saturday 04 August 2007 2:03:59 pm Rob Landley wrote:
> Signed-off-by: Rob Landley <rob@landley.net>
> Amiga part Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Move architecture-specific Documentation into a common subdirectory.
I really, really, really hate git.
Ok, on my laptop I just noticed that "git apply" of the patch didn't complain
but it also left the empty subdirectories it moved stuff out of. (I don't
believe this happened on the version of git I was using on my previous
laptop, which ate itself a month and change ago, but obviously I can't
check.)
There is no "git rmdir". "git rm" refuses to delete the directory
without -r. "git rm -r Documentation/x86_64" listed (as just deleted) all
the files that the patch already moved out of the directory.
Am I missing something obvious here?
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-04 19:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steven Grimm, Sam Ravnborg, Junio C Hamano, Ismail D?nmez, git
In-Reply-To: <alpine.LFD.0.999.0708041156550.5037@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 4 Aug 2007, David Kastrup wrote:
>> >
>> > You must be kidding. Texinfo is the worst documentation format EVER.
>>
>> Oh come on. It was the first hyperlinked and hierarchical format
>> before HTML even existed.
>
> Yes. And it should have died after html took its place.
The problem is that html, not even now, offers useful standardized
structural navigation information, so no reader can offer keypresses
to follow the non-existing information. I'd really like HTML to have
taken its place. However, in spite of all the bloat of HTML
processors (firefox takes more memory than Emacs, and Emacs is my
bloody _desktop_), and in spite of it being orders of magnitude
slower, it does not offer this navigation. It offers no cross-page
search facilities.
You can't navigate through the structure of the equivalent of hundreds
of printed pages in an HTML browser. Not by navigating, not by plain
text searching.
I'll be all set to bury Texinfo once HTML has taken its place.
Unfortunately, it has taken a different place up to now.
>> Actually, a decade ago the Emacs-internal info reader was worse
>> than it is now.
>
> Wow. I've used the emacs one, and the stand-alone info one, and both
> are pretty horrid. You're saying that they used to be _worse_?
The standalone reader was rather horrid a few years ago: it used not
to know the normal page and cursor commands and beeped at quite a few
things. It is quite better now. Bit it is not Emacs.
> (Admittedly, my GNU emacs-fu is very weak. I use an emacs-like
> editor, but it's just an editor, and it's subtly different, so I
> actually find the "real" emacs to be really disturbing on so many
> levels ;)
>
>> [ structure ]
>>
>> And as opposed to AsciiDoc, there _are_ readers that make use of
>> this information.
>
> None that any normal user would want to use.
Linus, do you really think that the editor _you_ use is used by more
people than Emacs? Think again.
Anyway, Emacs might, for all your polemics are worth, be an editor
that a "normal user" would not want to use: it has a tough learning
curve. It has considerably flattened in recent years, and
particularly Emacs 22 is a big step forward, but no sane person would
use Emacs if there was anything else that sucked less.
There isn't. And in spite of all your denial, there isn't for
Texinfo, either. You can't do a plain text search through hundreds of
HTML pages. You need a single page for that, and then navigation,
already bad in HTML, becomes absolutely horrid.
Your best bet nowadays might be a PDF reader with plain text search in
the document intended for printing. Something which has a page layout
and fonts not suited for screen reading.
You can't usefully find your way through a hundreds-pages manual page.
> The thing is, html does a much better job of all of that, simply
> because there are useful readers.
But there aren't. Not for documents of several hundred pages. Not
until you download all of them and then do a grep on the flat files
when you are looking for some keyword anywhere in the whole bunch.
That is an amount of suckage that neither Emacs nor the info reader
could ever hope to replicate.
> The same, btw, goes for man-pages: even though they have no
> structure at all, just the fact that normal people know how to use
> them, they are actually superior to info pages!
For single pages, yes. For hundreds of pages, this falls apart. Man
pages don't scale.
> That's something that the FSF seems to have missed in their push for
> info format: a lot of FSF programs have really substandard
> man-pages, but that doesn't mean that people read the info ones
> _anyway_. Because the readers are so disgustingly horrible, plain
> man-pages are actually much more useful, despite the fact that they
> don't have any cross-referencing etc.
Again, you presume to know the rest of the world, and the rest of the
world is "normal" and just like you.
I will readily agree with you that for the longest time, reading info
files outside of Emacs was painful enough to make it mostly useless.
With the current standalone info reader, it is merely annoying.
And inside of Emacs (and using Emacs is not as much the equivalent of
doing appendectomy on yourself with a fork because there is no
_equivalent_ to do the same job, but has progressed to a reasonably
sharp knife), info has moved from "tolerable" to "quite usable" under
Emacs 22: you can easily search whole documents, single nodes,
chapters. Pretty much everything is clickable by mouse (with mouse
button 1), including the structural information that _stays_ on top of
your window.
Anyway, like it or not, the current form of git documentation is not
structured, and that means that it is very hard to get the big
picture. Texinfo might have readers that suck, but other formats
don't have readers doing the job at all when we are talking about
finding your way in a document of some hundred pages. PDF at the
current point of time is about the closest you can come, and it is
print-oriented and slow. And it certainly does not offer something
like typing
i assembl RET
in order to jump through the index at the first page referring to
assembly language.
Like with TeX itself, the scandal is not that decade-old technology is
still in use, but rather that nobody has replaced it with anything
actually doing the same job, in spite of all the information being
freely available and in spite of the old technology being really
arcane.
Find me an HTML reader that allows keypress-based structured
navigation through documents of a few hundred pages, and _then_ talk
about Texinfo being supplanted.
Heck, _nobody_ likes Texinfo, including myself. It is a stupid format
and not remarkably fun to write or understand. It is just that there
are no bloody tools doing the same job. After all these years, and in
spite of a really terrible standalone reader for the longest time.
I can perfectly well understand your lack of enthusiasm. And feel
free to call me and the FSF and info and who- and whatever else any
name you like (you won't be able to refrain anyhow). But the fact
remains that the best way to find some information in the current git
documentation is not using HTML. It is not using man, unless you
already know what you are looking for.
No, currently the _only_ viable search interface into git's
documentation as a whole consists of grep and less.
And for your favorite "normal user" scapegoat, that sucks even worse
than the standalone info reader, let alone Emacs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: possible bug in git apply?
From: Junio C Hamano @ 2007-08-04 20:00 UTC (permalink / raw)
To: david; +Cc: git, rob
In-Reply-To: <Pine.LNX.4.64.0708041243070.6905@asgard.lang.hm>
david@lang.hm writes:
> since git doesn't track directories, only content (per the big
> discussion recently) I beleive that doing a checkout would leave Rob
> without the directories that he emptied out, so shouldn't git apply
> also clear the directories to end up in the same state?
It should and it does, unless you have untracked files in that
directory that you haven't told git about. Then removing the
directory along with these files will lose the files there,
which is a wrong thing to do.
A simple "rm -fr this/directory/is/no/longer/interesting/to/me"
would be all that is needed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox