* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-24 9:39 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20090324090014.GA2075@coredump.intra.peff.net>
On Tue, Mar 24, 2009 at 11:00 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 24, 2009 at 10:57:43AM +0200, Felipe Contreras wrote:
>
>> > Really? They look very different. Here's a screenshot of the user-manual
>> > with patches 2 and 3 from your series applied, next to Wikipedia. Your
>> > text is smaller, and the line-spacing makes it look more scrunched:
>> >
>> > http://peff.net/wikipedia-git-textsize.png
>>
>> Hmm, strange, can you tell me what is the configured font/font-size you have?
>
> FreeSans, 14pt (and I default to sans-serif for proportional text).
You're right, for some reason in that font it's the difference is much
more noticeable. Both Google and Wikipedia seem to be doing some
tricks scaling up and down the font-size. Still, in the end the
font-size looks very small on Gmail... strange.
So in the end Wikipedia: 91%, Gmail: 80%, Google: 86%... small is 79%.
I've updated it again, changing the 'green' color to something more
subtle and reverted all the font-size changes.
--- a/Documentation/docbook-xsl.css
+++ b/Documentation/docbook-xsl.css
@@ -15,9 +15,8 @@ body blockquote {
html body {
margin: 1em 5% 1em 5%;
- line-height: 1em;
+ line-height: 1.2;
font-family: sans-serif;
- font-size: small;
}
body div {
@@ -130,7 +129,7 @@ body pre {
tt.literal, code.literal {
color: navy;
- font-size: 1em;
+ font-family: sans-serif;
}
code.literal:before { content: "'"; }
@@ -138,7 +137,7 @@ code.literal:after { content: "'"; }
em {
font-style: italic;
- color: green;
+ color: #064;
}
div.literallayout p {
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Documentation: push.default applies to all remotes
From: Santi Béjar @ 2009-03-24 9:39 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Junio C Hamano, git
In-Reply-To: <20090324083015.GA22271@pvv.org>
Hi,
one thing I wonder is if push.default is too generic, maybe
push.style matches more the meaning.
Santi
^ permalink raw reply
* newbie question: git on existing svn repo via eclipse on windows
From: Michael Gaber @ 2009-03-24 9:22 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hello,
I hope I'm right here to post this question and it hasn't been answered
100k times already.
I'm currently programming my bachelor-thesis and my university only
gives me a svn repository. Since I'm working a big amount of time
offline I'd like to have the features a dvcs offers me to commit
whenever i have completed a minor step even while I'm offline, so I
don't forget what I've done until i get online again.
Is there a simple way to do this especially on windows while using
eclipse and egit.
Thanks Michael
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3643 bytes --]
^ permalink raw reply
* Re: [PATCH 4/8] Documentation: move quieting params into manpage-base.xsl
From: Jeff King @ 2009-03-24 9:18 UTC (permalink / raw)
To: Chris Johnsen; +Cc: git, Junio C Hamano
In-Reply-To: <1237881866-5497-5-git-send-email-chris_johnsen@pobox.com>
On Tue, Mar 24, 2009 at 03:04:22AM -0500, Chris Johnsen wrote:
> I am not sure why these were only in the -1.72 variant. They
> should probably be in -base (done by this patch) or in neither
> variant. If there is a good reason for having it only in -1.72,
> this patch can be dropped entirely, the rest do not depend on it.
Digging through the archive, it is hard to say. The original patch
mentions DOCBOOK_XSL_172 as if callouts.xsl were already doing this, but
I don't see any evidence that it ever did.
Definitely an improvement, IMHO. I wonder if we also want to consider
making the "make" output a little nicer to Documentation/Makefile,
similar to how the main Makefiles just prints "CC".
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Jeff King @ 2009-03-24 9:16 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Michael J Gruber, git
In-Reply-To: <94a0d4530903240206k6eecdabg2cbb2c5595cd4bc@mail.gmail.com>
On Tue, Mar 24, 2009 at 11:06:50AM +0200, Felipe Contreras wrote:
> Take a look at:
> http://people.freedesktop.org/~felipec/git/user-manual.html#bisect-merges
>
> Do you think slanting Z (and the other characters) is enough to emphasize it?
I think it looks better with color to emphasize that it is different,
just as the <code> blocks get monospaced _and_ colored.
However, I think this is a matter of poor semantic markup in the first
place. Italics on a word for emphasis in text is very different from
what is happening here, which is essentially typesetting math variables.
I would say that `Z` is probably a better match, though I prefer the
LaTeX-style "math mode" italics for this sort of thing. I think asciidoc
supports some math markup, but I haven't lookd at it.
So basically, I think these variables look fine slanted and green. But I
think an emphasized word in the text should not be green.
-Peff
^ permalink raw reply
* Re: GIT BUG? GIT occasionally redownloads its entire data set
From: David Howells @ 2009-03-24 9:15 UTC (permalink / raw)
To: Dmitry Potapov
Cc: dhowells, Junio C Hamano, git, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <37fcd2780903231953pdfaa679r8a680f64ee692c8d@mail.gmail.com>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> It was fixed in Git 1.5.5 if I am not mistaken.
warthog>rpm -q git
git-1.5.4.3-3.fc8
It looks like I'm using a version of GIT that's just a little bit too old.
David
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Junio C Hamano @ 2009-03-24 9:13 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <7vljqv2t05.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> $ git push --dry-run sf.net
> warning: You did not specify any refspecs to push, and the current remote
> warning: has not configured any push refspecs. The default action in this
> warning: case is to push all matching refspecs, that is, all branches
> warning: that exist both locally and remotely will be updated. This may
> warning: not necessarily be what you want to happen.
> warning:
> warning: You can specify what action you want to take in this case, and
> warning: avoid seeing this message again, by configuring 'push.default' to:
> warning: 'nothing' : Do not push anythig
> warning: 'matching' : Push all matching branches (default)
> warning: 'tracking' : Push the current branch to whatever it is tracking
> warning: 'current' : Push the current branch
> fatal: 'sf.net' does not appear to be a git repository
> fatal: The remote end hung up unexpectedly
>
> The final, most important error messages are dwarfed out by the warning
> that talks about setting configuration on the remote that does not even
> exist.
Actually, I take it back. It is still annoying, but the point of these
warning lines is to warn even for a one-off push you make to a place
without having any [remote "sf.net"] entry anywhere in the config. In the
worst case, the above "sf.net" may even be just a full URL of the remote,
and we do want to trigger the warning.
So this is not even a usability bug. Sorry for a thinko.
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-24 9:06 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <49C899E1.6060809@drmicha.warpmail.net>
On Tue, Mar 24, 2009 at 10:29 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 24.03.2009 01:21:
>> On Mon, Mar 23, 2009 at 5:20 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Felipe Contreras venit, vidit, dixit 23.03.2009 11:31:
>>>> On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@peff.net> wrote:
>>>>> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>>>>>
>>>>>> tt.literal, code.literal {
>>>>>> color: navy;
>>>>>> + font-size: 1em;
>>>>>> +}
>>>>>
>>>>> Isn't 1em already the default size? Or are you trying to override some
>>>>> other size specification elsewhere? It's hard to tell what the goal is
>>>>> because your commit message merely says "improve".
>>>>
>>>> That's correct.
>>>>
>>>> The problem is that when the user has a different size for the
>>>> sans-serif and monospace fonts it looks horrible when they are on the
>>>> same paragraph. I thought 1em did the trick, but you are right, it
>>>> doesn't.
>>>>
>>>> It looks like the only way to fix this is to set absolute sizes.
>>>>
>>>
>>> Also, it seems that everything which is not black is blue, except for
>>> terms, which are green and slanted. I don't think that looks nice
>>> together. How about slanted blue?
>>
>> What's wrong with having 2 colors?
>
> I don't mind having 2, they just don't look good together over here, on
> my screen and to my eyes...
>
> Right now we have "plain old asciidoc look" which doesn't look that old
> after all. You pointed out a deficiency, and I'm all for fixing it. I
> just think that introducing new colors is something that may require a
> ground up rethinking of the theme being used: make it informative but
> unobtrusive. Also, I'm against over-emphasizing: use slanted or a
> specific color, but not both. Unless one color means emphasizing and
> slanted means file, for example.
Take a look at:
http://people.freedesktop.org/~felipec/git/user-manual.html#bisect-merges
Do you think slanting Z (and the other characters) is enough to emphasize it?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 3/8] Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff
From: Jeff King @ 2009-03-24 9:04 UTC (permalink / raw)
To: Chris Johnsen; +Cc: git, Junio C Hamano
In-Reply-To: <1237881866-5497-4-git-send-email-chris_johnsen@pobox.com>
On Tue, Mar 24, 2009 at 03:04:21AM -0500, Chris Johnsen wrote:
> It seems that the ability to use raw roff codes in asciidoc.conf
> was eliminated by docbook-xsl 1.72.0 _and later_. Unlike the
> 1.72.0-specific XSLT problem, this behavior was not reverted in
> later releases.
>
> This patch aims to make it clear that the affected asciidoc
> attribute (flag) can be reasonably used with docbook-xsl versions
> other than 1.72.0.
Great, this looks like a definite improvement. Should we be respecting
more DOCBOOK_XSL_* variables than just 172, then? I.e.,:
> +# For docbook-xsl ...
> +# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)
> +# 1.69.0-1.71.1, no extra settings are needed?
> +# 1.72.0, set DOCBOOK_XSL_172.
> +# 1.73.0-, set ASCIIDOC_NO_ROFF
DOCBOOK_XSL_173, etc?
I don't know that we need to cover _every_ version, but if we can have
specific knobs for individual features (like ASCIIDOC_NO_ROFF), then
maybe it makes sense to aggregate the settings for those knobs for a few
common versions.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)
From: Junio C Hamano @ 2009-03-24 9:02 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git
In-Reply-To: <7v4oxk6wk2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Finn Arne Gangstad <finnag@pvv.org> writes:
>
>> If you feel that talking about a possible future change is premature,
>> you could omit that part of the second commit I guess, but I think
>> printing some kind of warning is valuable. Are you waiting for more
>> input? It seems that this topic is pretty dead now.
Now it turns out that it has been "pretty dead" because nobody, not even
the original author, was doing any testing and fixing.
After merging this "warning" thing to next, I mistype the name of the
remote I wanted to push with the default "matching" semantics and got this:
$ git push --dry-run sf.net
warning: You did not specify any refspecs to push, and the current remote
warning: has not configured any push refspecs. The default action in this
warning: case is to push all matching refspecs, that is, all branches
warning: that exist both locally and remotely will be updated. This may
warning: not necessarily be what you want to happen.
warning:
warning: You can specify what action you want to take in this case, and
warning: avoid seeing this message again, by configuring 'push.default' to:
warning: 'nothing' : Do not push anythig
warning: 'matching' : Push all matching branches (default)
warning: 'tracking' : Push the current branch to whatever it is tracking
warning: 'current' : Push the current branch
fatal: 'sf.net' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
The final, most important error messages are dwarfed out by the warning
that talks about setting configuration on the remote that does not even
exist.
In this particular case, it does not corrupt the local nor remote
repositories, and because it was me who tried this who knew what he was
doing, so it is Ok, and that is the point of keeping any new features out
of 'master' until such silly misfeatures are found and fixed. But it
would have been nicer if I weren't the only one testing and finding bugs.
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Jeff King @ 2009-03-24 9:00 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <94a0d4530903240157v2b9aa91dh4c731b77de9d7b58@mail.gmail.com>
On Tue, Mar 24, 2009 at 10:57:43AM +0200, Felipe Contreras wrote:
> > Really? They look very different. Here's a screenshot of the user-manual
> > with patches 2 and 3 from your series applied, next to Wikipedia. Your
> > text is smaller, and the line-spacing makes it look more scrunched:
> >
> > http://peff.net/wikipedia-git-textsize.png
>
> Hmm, strange, can you tell me what is the configured font/font-size you have?
FreeSans, 14pt (and I default to sans-serif for proportional text).
> Regarding the line-space I already changed that as you suggested:
> file:///data/public/src/git/Documentation/user-manual.html
I had a little trouble fetching that URL. ;)
But yes, I saw that you did.
-Peff
^ permalink raw reply
* Re: large(25G) repository in git
From: Andreas Ericsson @ 2009-03-24 8:59 UTC (permalink / raw)
To: Adam Heath; +Cc: git
In-Reply-To: <49C7FAB3.7080301@brainfood.com>
Adam Heath wrote:
> We maintain a website in git. This website has a bunch of backend
> server code, and a bunch of data files. Alot of these files are full
> videos.
>
First of all, I'm going to hint that you would be far better off
keeping the media files in a separate repository, linked in as a
submodule in git and with tweaked configuration settings with the
specific aim of handling huge files.
The basis of such a repository is probably the following config
settings, since media files very rarely compress enough to be
worth the effort, and their own compressed formats make them
very unsuitable delta candidates:
[pack]
# disable delta-based packing
depth = 1
# disable compression
compression = 0
[gc]
# don't auto-pack, ever
auto = 0
# never automatically consolidate un-.keep'd packs
autopacklimit = 0
You will have to manually repack this repository from time to
time, and it's almost certainly a good idea to mark the
resulting packs with .keep to avoid copying tons of data.
When packs are being created, objects can be copied from
existing packs, and send-pack will make use of that so that what
goes over the wire will simply be copied from the existing packs.
YMMV. If you do come up with settings that work fine for huge
repos made up of mostly media files, please share your findings.
> We use git, so that the distributed nature of website development can
> be supported. Quite often, you'll have a production server, with
> online changes occurring(we support in-browser editting of content), a
> preview server, where large-scale code changes can be previewed, then
> a development server, one per programmer(or more).
>
> Last friday, I was doing a checkin on the production server, and found
> 1.6G of new files. git was quite able at committing that. However,
> pushing was problematic. I was pushing over ssh; so, a new ssh
> connection was open to the preview server. After doing so, git tried
> to create a new pack file. This took *ages*, and the ssh connection
> died. So did git, when it finally got done with the new pack, and
> discovered the ssh connection was gone.
>
> So, to work around that, I ran git gc. When done, I discovered that
> git repacked the *entire* repository. While not something I care for,
> I can understand that, and live with it. It just took *hours* to do so.
>
I'm not sure what, if any, magic "git gc" applies before spawning
"git repack", but running "git repack" directly would almost certainly
have produced an incremental pack. Perhaps we need to make gc less
magic.
> Then, what really annoys me, is that when I finally did the push, it
> tried sending the single 27G pack file, when the remote already had
> 25G of the repository in several different packs(the site was an
> hg->git conversion). This part is just unacceptable.
>
Agreed. I've never run across that problem, so I can only assume it
has something to do with many huge files being in the pack.
> So, here are my questions/observations:
>
> 1: Handle the case of the ssh connection dying during git push(seems
> simple).
>
Not necessarily all that simple (we do not want to touch the ssh
password if we can possibly avoid it, but the user shouldn't have
to type it more than once), but certainly doable. Easier would
probably be to recommend adding the proper SSH config variables,
as has been stated elsewhere.
> 2: Is there an option to tell git to *not* be so thorough when trying
> to find similiar files. videos/doc/pdf/etc aren't always very
> deltafiable, so I'd be happy to just do full content compares.
>
See above. I *think* you can also do this with git-attributes, but
I'm not sure. However, keeping the large media files in a sub-module
would nicely solve that problem anyway, and is probably a good idea
even with git-attributes support for pack delta- and compression
settings.
> 3: delta packs seem to be poorly done. it seems that if one repo gets
> repacked completely, that the entire new pack gets sent, when the
> target has most of the objects already.
>
This is certainly not the case for most repositories. I believe there's
something being triggered from repositories with many huge files though.
> 4: Are there any config options I can set to help in this? There are
> tons of options, and some documentation as to what each one does, but
> no recommended practices type doc, that describes what should be done
> for different kinds of workflows.
>
http://www.thousandparsec.net/~tim/media+git.pdf probably holds all the
relevant information when it comes to storing large media files with
git. I have not checked and have no inclination to do so.
> ps: Thank you for your time. I hope that someone has answers for me.
>
Answers aplenty, I hope. I have neither time nor interest in developing
this though, so the task of creating patches and/or documentation will
have to fall to someone else.
> pps: I'm not subscribed, please cc me. If I need to be subscribed,
> I'll do so, if told.
Subscribing won't be necessary. The custom on git@vger is to always Cc
all who participate in the discussion, and only cull those who state
they're no longer interested in the topic.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH 2/8] Documentation: use parametrized manpage-base.xsl with manpage-{1.72,normal}.xsl
From: Jeff King @ 2009-03-24 8:57 UTC (permalink / raw)
To: Chris Johnsen; +Cc: git, Junio C Hamano
In-Reply-To: <1237881866-5497-3-git-send-email-chris_johnsen@pobox.com>
On Tue, Mar 24, 2009 at 03:04:20AM -0500, Chris Johnsen wrote:
> +<!-- manpage-1.72.xsl:
> + special settings for manpages rendered from asciidoc+docbook
> + must be used with manpage-base.xsl
> + handles peculiarities in docbook-xsl 1.72.0 -->
Hmm. I'm not sure I understood all of the issues you ran into that you
mentioned in the commit message (but trust me, having tried to do
anything with docbook, I can sympathize with the frustration you
probably felt), so maybe I am missing something. But is it not possible
to <xsl:include> manpage-base here, rather than a comment saying "Make
sure you have already included it"?
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-24 8:57 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20090324081846.GB660@coredump.intra.peff.net>
On Tue, Mar 24, 2009 at 10:18 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Mar 24, 2009 at 09:52:33AM +0200, Felipe Contreras wrote:
>
>> > By the way, are you using a font that is a bit smaller than the body text
>> > to render the examples? I find it harder to read.
>>
>> Why do people have problems reading small fonts? That's exactly the
>> same font-size you'll see on Wikipedia, Google, and many other sites:
>> 'small'. Do you have problems reading Wikipedia?
>
> Really? They look very different. Here's a screenshot of the user-manual
> with patches 2 and 3 from your series applied, next to Wikipedia. Your
> text is smaller, and the line-spacing makes it look more scrunched:
>
> http://peff.net/wikipedia-git-textsize.png
Hmm, strange, can you tell me what is the configured font/font-size you have?
Regarding the line-space I already changed that as you suggested:
file:///data/public/src/git/Documentation/user-manual.html
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/8] Documentation: move callouts.xsl to manpage-{base,normal}.xsl
From: Jeff King @ 2009-03-24 8:51 UTC (permalink / raw)
To: Chris Johnsen; +Cc: git, Junio C Hamano
In-Reply-To: <1237881866-5497-2-git-send-email-chris_johnsen@pobox.com>
On Tue, Mar 24, 2009 at 03:04:19AM -0500, Chris Johnsen wrote:
> Documentation/Makefile | 2 +-
> Documentation/callouts.xsl | 30 ------------------------------
> Documentation/manpage-base.xsl | 30 ++++++++++++++++++++++++++++++
> Documentation/manpage-normal.xsl | 30 ++++++++++++++++++++++++++++++
> 4 files changed, 61 insertions(+), 31 deletions(-)
> delete mode 100644 Documentation/callouts.xsl
> create mode 100644 Documentation/manpage-base.xsl
> create mode 100644 Documentation/manpage-normal.xsl
This is definitely a good change, though it would also be fine to
actually munge the contents in the same patch rather than duplicate them
(i.e., actually _split_ callouts.xsl instead of copying it to two
places).
I think it would have been much easier to read, though, by turning on
rename detection in format-patch (i.e., "-M"). That yields:
---
Documentation/Makefile | 2 +-
Documentation/{callouts.xsl => manpage-base.xsl} | 0
Documentation/{callouts.xsl => manpage-normal.xsl} | 0
3 files changed, 1 insertions(+), 1 deletions(-)
copy Documentation/{callouts.xsl => manpage-base.xsl} (100%)
rename Documentation/{callouts.xsl => manpage-normal.xsl} (100%)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 144ec32..e1562e3 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -41,7 +41,7 @@ man7dir=$(mandir)/man7
ASCIIDOC=asciidoc
ASCIIDOC_EXTRA =
-MANPAGE_XSL = callouts.xsl
+MANPAGE_XSL = manpage-normal.xsl
INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
diff --git a/Documentation/callouts.xsl b/Documentation/manpage-base.xsl
similarity index 100%
copy from Documentation/callouts.xsl
copy to Documentation/manpage-base.xsl
diff --git a/Documentation/callouts.xsl b/Documentation/manpage-normal.xsl
similarity index 100%
rename from Documentation/callouts.xsl
rename to Documentation/manpage-normal.xsl
--
1.6.2.1.459.g5b99e
^ permalink raw reply related
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Jeff King @ 2009-03-24 8:42 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530903231720r620e44fu90dd77a3231bd4d1@mail.gmail.com>
On Tue, Mar 24, 2009 at 02:20:13AM +0200, Felipe Contreras wrote:
> I've updated the CSS. Can you take a look again?
>
> I changed the font-size to normal, except for the code chunks. Also, I
Well, it looks better to me, in that the body text isn't small and
scrunched. The code chunks are, of course, noticeably smaller. I really
don't see what you're trying to accomplish with that. Are you trying to
make it fit into browsers where we are somehow wrapping in the code
chunks?
> changed the font of the in-paragrah code tags to sans-serif, that's
> the most sane way I can think to fix the problem with different
> font-size configured for monospace font.
Hrm. I'm not sure that is particularly sane. You have the style for a
<tt> tag rendering as a sans-serif font. But the _definition_ of tt is
to render as a monospace font.
As it happens, there are no <tt> tags at all in the document, so that
change is irrelevant (and I wonder if we should ditch the tt.literal
specifier entirely). But I tend to think that <code> tags generally
follow the same principle. Looking over the document, I didn't find
anything that looked broken by it (at least in Firefox using my set of
fonts). But it just seems counterintuitive.
If you are unsatisfied with the size of the text in <code> blocks,
can't you set some variant of an em (e.g., 1.1em)?
Looking at all of these <code> examples did make me notice one thing:
there are some special characters used that are probably
counterintuitive. For instance, "--not" is rendered with a single long
dash instead of two short dashes. A code snippet has a right-arrow
character instead of "->". I assume this is asciidoc trying to be
clever, but I haven't looked into it.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: push.default applies to all remotes
From: Finn Arne Gangstad @ 2009-03-24 8:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Santi Béjar
In-Reply-To: <7v7i2f6cj7.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 23, 2009 at 04:32:28PM -0700, Junio C Hamano wrote:
> Santi Béjar <santi@agolina.net> writes:
>
> > push.default is not only for the current remote but setting the default
> > behavior for all remotes.
> >
> > Signed-off-by: Santi Béjar <santi@agolina.net>
> > ---
> > Hi,
> >
> > this applies on top of next.
> >
> > Documentation/config.txt | 11 +++--------
> > 1 files changed, 3 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 089569a..7f5fe43 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -1215,19 +1215,14 @@ push.default::
> > Defines the action git push should take if no refspec is given
> > on the command line, no refspec is configured in the remote, and
> > no refspec is implied by any of the options given on the command
> > - line.
> > -+
> > -The term `current remote` means the remote configured for the current
> > -branch, or `origin` if no remote is configured. `origin` is also used
> > -if you are not on any branch. Possible values are:
> > + line. Possible values are:
> > +
> > * `nothing` do not push anything.
> > -* `matching` push all matching branches to the current remote.
> > +* `matching` push all matching branches.
> > All branches having the same name in both ends are considered to be
> > matching. This is the current default value.
> > * `tracking` push the current branch to the branch it is tracking.
> > -* `current` push the current branch to a branch of the same name on the
> > - current remote.
> > +* `current` push the current branch to a branch of the same name.
> >
> > rebase.stat::
> > Whether to show a diffstat of what changed upstream since the last
> [...]
> If we want to explain that a "git push" that does not say where-to decides
> where to push by looking at branch.<name>.remote configuration and falling
> back to origin, push.default is not the place to explain it. This
> configuration variable is not involved in that decision in any way.
I originally had an option to push all tracking branches to their
respective counterparts here, but decided against including it. Then
it made sense to distinguish which options pushed to the current
remote, and which did not. Since that option is gone, removing the
extra text seems like an improvement.
- Finn Arne
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Michael J Gruber @ 2009-03-24 8:29 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <94a0d4530903231721i2a2a6fc1yf54d4303283ec415@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 24.03.2009 01:21:
> On Mon, Mar 23, 2009 at 5:20 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Felipe Contreras venit, vidit, dixit 23.03.2009 11:31:
>>> On Mon, Mar 23, 2009 at 8:42 AM, Jeff King <peff@peff.net> wrote:
>>>> On Sun, Mar 22, 2009 at 08:05:15PM +0200, Felipe Contreras wrote:
>>>>
>>>>> tt.literal, code.literal {
>>>>> color: navy;
>>>>> + font-size: 1em;
>>>>> +}
>>>>
>>>> Isn't 1em already the default size? Or are you trying to override some
>>>> other size specification elsewhere? It's hard to tell what the goal is
>>>> because your commit message merely says "improve".
>>>
>>> That's correct.
>>>
>>> The problem is that when the user has a different size for the
>>> sans-serif and monospace fonts it looks horrible when they are on the
>>> same paragraph. I thought 1em did the trick, but you are right, it
>>> doesn't.
>>>
>>> It looks like the only way to fix this is to set absolute sizes.
>>>
>>
>> Also, it seems that everything which is not black is blue, except for
>> terms, which are green and slanted. I don't think that looks nice
>> together. How about slanted blue?
>
> What's wrong with having 2 colors?
I don't mind having 2, they just don't look good together over here, on
my screen and to my eyes...
Right now we have "plain old asciidoc look" which doesn't look that old
after all. You pointed out a deficiency, and I'm all for fixing it. I
just think that introducing new colors is something that may require a
ground up rethinking of the theme being used: make it informative but
unobtrusive. Also, I'm against over-emphasizing: use slanted or a
specific color, but not both. Unless one color means emphasizing and
slanted means file, for example.
Michael
^ permalink raw reply
* Re: [RFC/WIP 0/2] Documentation clean-up: git commands
From: Michael J Gruber @ 2009-03-24 8:24 UTC (permalink / raw)
To: Chris Johnsen; +Cc: Junio C Hamano, git
In-Reply-To: <37FD43AD-E43A-4565-8085-95E606E0B868@pobox.com>
Chris Johnsen venit, vidit, dixit 24.03.2009 00:13:
> On 2009 Mar 23, at 11:22, Junio C Hamano wrote:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> - Do we want it this way (`git command`)?
>>
>> That's my personal preference but other people may differ; wasn't
>> there an
>> issue with "man" backend losing the typesetting information?
>
> An issue that came up recently was that the backticks seem to have no
> typeset representation in the official kernel.org manpages.
The man backend seems to handle ` and ' differently, that's true. But
that's an issue of the asciidoc configuration in combination with the
docbook stylesheets. In any case, backticks are for commands.
I'm grateful if you look into the asciidoc/docbook issues. We also have
compatibility issues going on there between different asciidoc 8
versions, as well as docbook versions.
> In my recent fumbling with the documentation generation, I have often
> been using git-init.txt as a "test bed". It shows clearly enough that
> backticks, by themselves, are not represented in the official manpages:
>
> $ git grep core/templates Documentation/git-init.txt
> Documentation/git-init.txt:directory is `/usr/share/git-core/
> templates`.
>
> There we see the path in backticks with a period outside the
> backticks. If any inline typesetting were to come between "core/
> templates" and ".", I think this command would turn it up:
>
> $ git log -p -Score/templates. origin/man -- man1/git-init.1
>
> It gets two hits. The first where the sentence is introduced, and a
> second where the period is escaped:
>
> 43e513c (Autogenerated man pages for v1.5.0-rc1, 2007-01-12)
> 2cbdf46 (Autogenerated manpages for v1.5.6.2-212-g08b5, 2008-07-06)
>
> The last one leaves us with "core/templates\.". So search again to
> see if that has changed since the last one:
>
> git log -p -Score/templates\\. origin/man -- man1/git-init.1
>
> Nope, that only shows the one hit (2cbdf46). In case I made an error
> using the `git log` to do the searching, I also checked by hand by
> loading the diffs from <http://git.kernel.org/?p=git/
> git.git;a=history;f=man1/git-init.1;hb=man> (they agree, no
> formatting around that path in any of the generated git-init.1).
>
> When I generate the manpage on my machine (asciidoc 8.3.1; docbook-
> xsl 1.74.0), I do get some formatting for backticks:
>
> $ grep core/templates Documentation/git-init.1
> Provide the directory from which templates will be used\&. The
> default template directory is \FC/usr/share/git\-core/templates\F[]\&.
>
> From what I can tell the \FC is supposed to introduce monospace type
> and \F[] is to reset to the previous type. When I run it through
> groff -man -Tps, it does come out in a monospaced font. The change
> in font is not obvious when viewing the manpage in a tty-based
> manpage viewer (which was my original "gripe"), but there is some
> typesetting info there for pages I generate.
>
> I suspect the main difference between my generated pages and the
> official pages (at least for typesetting of literal text) is the
> docbook-xsl version (though I have not dug into previous versions of
> dcobook-xsl to bolster this hypothesis).
>
> I have a series of patches prepared to "cleanup" and modify
> {callout,manpage-1.72}.xsl and asciidoc.conf, but I am still running
> a series of "make doc" runs across the changes to try to make sure
> they are sane. Here is a preview:
>
> Documentation: move callouts.xsl to manpage-{base,normal}.xsl
> Documentation: use parametrized manpage-base.xsl with manpage-
> {1.72,normal}.xsl
> Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff
> Documentation: move quieting params into manpage-base.xsl
> Documentation: move "spurious .sp" code into manpage-base.xsl
> Documentation: asciidoc.conf: always use <literallayout> for [blocktext]
> Documentation: asciidoc.conf: fix verse block with block titles
> Documentation: option to render literal text as italic for manpages
>
> The first three restructure things a bit. The next three make some
> cleanups that could be dropped if they are deemed inappropriate. The
> last one add an option that changes the manpage formatting used
> around asciidoc backticked strings (literal text).
>
> I plan on sending the patches along after my trial doc-generations
> finish and I have reviewed the results (my machine is slow, it may
> not be until tomorrow).
>
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Jeff King @ 2009-03-24 8:18 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <94a0d4530903240052x2c6b882aub7de6d46e9949ddb@mail.gmail.com>
On Tue, Mar 24, 2009 at 09:52:33AM +0200, Felipe Contreras wrote:
> > By the way, are you using a font that is a bit smaller than the body text
> > to render the examples? I find it harder to read.
>
> Why do people have problems reading small fonts? That's exactly the
> same font-size you'll see on Wikipedia, Google, and many other sites:
> 'small'. Do you have problems reading Wikipedia?
Really? They look very different. Here's a screenshot of the user-manual
with patches 2 and 3 from your series applied, next to Wikipedia. Your
text is smaller, and the line-spacing makes it look more scrunched:
http://peff.net/wikipedia-git-textsize.png
-Peff
^ permalink raw reply
* Re: How to go to git from svn without checkout
From: Jeff King @ 2009-03-24 8:10 UTC (permalink / raw)
To: Samman, Bassel; +Cc: git
In-Reply-To: <FB1F526D99571D4DBF84F456D358792901CC7F6F@leasrv003.imagitek.local>
On Mon, Mar 23, 2009 at 10:21:41AM -0500, Samman, Bassel wrote:
> Yes, unfortunately they do change occasionally and they grow with
> time. It's a product catalogue, so new products are added all the
> time, just not daily. That's part of why I want to move to Git, SVN
Well, I would first try just importing _one_ repo into git and seeing
how it behaves. I suspect you may run into assumptions that a 50G repo
breaks.
In theory, I think you could pack all of the large files once into a
single pack, mark it with .keep, and then not have it negatively impact
further repacks.
> has been giving me lots of trouble when adding files at deep levels
> and I like how Git does adding files and how each repository is really
> it's own repository. Also, I'm not really concerned about history as
> the main purpose of the repository is really to make the syncing job
> easier. The code is very minimal and I do the majority of the
Well, if you're not too concerned about the history, then I would
suggest setting up something like this:
- all of the big files get a unique name; new versions of the same
file have names unique from their previous version (you can do this
either with human-readable names, or just using the sha-1 of the
file contents)
- make all of the big files available through rsync, http, ftp, or
whatever
- the git (or svn) repo contains a list of all desired files, and a
script that checks what you have versus what is desired (deleting
any that aren't wanted, and pulling any that are missing)
Your repository of big files will grow, but each file within it is
immutable. The git repository points to the files by name, but doesn't
contain them. So updating from a client is just:
git pull && ./update-script
but you can still go back to a snapshot in history if you want to:
git checkout HEAD@{3.weeks.ago} && ./update-script
Make sense?
> can be crazy at times, but what can we do. Also, this is a far fetch,
> since all the projects are installed under the same directories and
> are really exact clones of each other in every way, can I copy the
> .git directory and hope to God that it will magically work. I really
> doubt it, but I figure it's worth asking.
I'm not sure what you mean by that. You can copy the .git directory to a
new working tree, yes. It will be a new repo, and you can see how what
it thinks should be checked out differs from what is in the new working
tree by running "git diff".
-Peff
^ permalink raw reply
* [PATCH 8/8] Documentation: option to render literal text as bold for manpages
From: Chris Johnsen @ 2009-03-24 8:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Chris Johnsen
In-Reply-To: <1237881866-5497-1-git-send-email-chris_johnsen@pobox.com>
This allows manpages viewed on a tty to render inline literal
text in a manner that is distinct from the surrounding text.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
Since dobcook-xsl 1.74.0 seems to introduce using a monospace
font for literal text (asciidoc backticks), this patch may not be
so important for end users that can install their own
docbook-xsl.
But this patch, or something like it, might be useful for
introducing some kind of typesetting for literal text in the
official manpages (since it would not require upgrading
docbook-xsl). It could probably even be changed/extended to
provide monospacing without using a new docbook-xsl.
The functionality is optional and defaults to "off", so there
probably is not too much harm in including it, even if it is not
used for the official manpages.
---
Documentation/Makefile | 6 +++++-
Documentation/manpage-bold-literal.xsl | 17 +++++++++++++++++
2 files changed, 22 insertions(+), 1 deletions(-)
create mode 100644 Documentation/manpage-bold-literal.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 11b26aa..238ff83 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -42,6 +42,7 @@ man7dir=$(mandir)/man7
ASCIIDOC=asciidoc
ASCIIDOC_EXTRA =
MANPAGE_XSL = manpage-normal.xsl
+XMLTO_EXTRA =
INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
@@ -93,6 +94,9 @@ else
ASCIIDOC_EXTRA += -a git-asciidoc-no-roff
endif
endif
+ifdef MAN_BOLD_LITERAL
+XMLTO_EXTRA += -m manpage-bold-literal.xsl
+endif
#
# Please note that there is a minor bug in asciidoc.
@@ -192,7 +196,7 @@ $(MAN_HTML): %.html : %.txt
%.1 %.5 %.7 : %.xml
$(RM) $@
- xmlto -m $(MANPAGE_XSL) -m manpage-base.xsl man $<
+ xmlto -m $(MANPAGE_XSL) $(XMLTO_EXTRA) -m manpage-base.xsl man $<
%.xml : %.txt
$(RM) $@+ $@
diff --git a/Documentation/manpage-bold-literal.xsl b/Documentation/manpage-bold-literal.xsl
new file mode 100644
index 0000000..608eb5d
--- /dev/null
+++ b/Documentation/manpage-bold-literal.xsl
@@ -0,0 +1,17 @@
+<!-- manpage-bold-literal.xsl:
+ special formatting for manpages rendered from asciidoc+docbook -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+
+<!-- render literal text as bold (instead of plain or monospace);
+ this makes literal text easier to distinguish in manpages
+ viewed on a tty -->
+<xsl:template match="literal">
+ <xsl:value-of select="$git.docbook.backslash"/>
+ <xsl:text>fB</xsl:text>
+ <xsl:apply-templates/>
+ <xsl:value-of select="$git.docbook.backslash"/>
+ <xsl:text>fR</xsl:text>
+</xsl:template>
+
+</xsl:stylesheet>
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* [PATCH 6/8] Documentation: asciidoc.conf: always use <literallayout> for [blocktext]
From: Chris Johnsen @ 2009-03-24 8:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Chris Johnsen
In-Reply-To: <1237881866-5497-1-git-send-email-chris_johnsen@pobox.com>
Make the docbook-xsl-no-raw-roff variant match the
no-docbook-xsl-no-raw-roff variant in terms of which XML tag is
used to wrap listing block text (delimited with lines of dashes).
e920b56 (Tweak asciidoc output to work with broken docbook-xsl,
2006-03-05) says docbook-xsl 1.68 needs <literallayout>. This
<screen> usages was in the old, 1.72-only section. But since it
is now the "roff-less" section, it probably makes sense to make it
symmetric with the "roff-ful" section.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
This is another cleanup to make the two conditional sections more
symmetric.
The only large, remaining asymmetry in the asciidoc.conf
roff/non-roff parts is the [verseblock] in the non-roff
section. Should [verseblock] be pulled out of the
roff-conditional parts? Should a [verseblock] section be added
to the roff-using part?
---
Documentation/asciidoc.conf | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index ce1b175..9963f2d 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -49,9 +49,9 @@ ifdef::doctype-manpage[]
# The following two small workarounds insert a simple paragraph after screen
[listingblock]
<example><title>{title}</title>
-<screen>
+<literallayout>
|
-</screen><simpara></simpara>
+</literallayout><simpara></simpara>
{title#}</example>
[verseblock]
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* [PATCH 7/8] Documentation: asciidoc.conf: fix verse block with block titles
From: Chris Johnsen @ 2009-03-24 8:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Chris Johnsen
In-Reply-To: <1237881866-5497-1-git-send-email-chris_johnsen@pobox.com>
No files use the variant of block-title with verse-block, but
such a case would have generated broken docbook XML (<simpara> is
not allowed inside <para>). This fixes the potential deviation from
valid docbook XML.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
This is a bugfix for a bug that the documentation currently does
not trigger. Drop this patch if this is unwarranted.
---
Documentation/asciidoc.conf | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 9963f2d..dc76e7f 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -59,8 +59,9 @@ ifdef::doctype-manpage[]
{title%}<literallayout{id? id="{id}"}>
{title#}<literallayout>
|
-</literallayout><simpara></simpara>
+</literallayout>
{title#}</para></formalpara>
+{title%}<simpara></simpara>
endif::doctype-manpage[]
endif::git-asciidoc-no-roff[]
endif::backend-docbook[]
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* [PATCH 5/8] Documentation: move "spurious .sp" code into manpage-base.xsl
From: Chris Johnsen @ 2009-03-24 8:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Chris Johnsen
In-Reply-To: <1237881866-5497-1-git-send-email-chris_johnsen@pobox.com>
The "spurious .sp" code should be independent of docbook-xsl
versions.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
I do not know why this was only in the non-1.72 variant. Maybe
docbook-xsl 1.72.0 did not need it. But it does not seem like it
would hurt to push it into the shared XSLT. As before, if there
is a good reason to keep it out of the -1.72 processing, then
just drop this patch, none of the rest depend on it.
---
Documentation/manpage-base.xsl | 13 +++++++++++++
Documentation/manpage-normal.xsl | 13 -------------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl
index a264fa6..16e2e40 100644
--- a/Documentation/manpage-base.xsl
+++ b/Documentation/manpage-base.xsl
@@ -32,4 +32,17 @@
<xsl:text>br </xsl:text>
</xsl:template>
+<!-- attempt to work around spurious .sp at the tail of the line
+ that docbook stylesheets seem to add -->
+<xsl:template match="simpara">
+ <xsl:variable name="content">
+ <xsl:apply-templates/>
+ </xsl:variable>
+ <xsl:value-of select="normalize-space($content)"/>
+ <xsl:if test="not(ancestor::authorblurb) and
+ not(ancestor::personblurb)">
+ <xsl:text> </xsl:text>
+ </xsl:if>
+</xsl:template>
+
</xsl:stylesheet>
diff --git a/Documentation/manpage-normal.xsl b/Documentation/manpage-normal.xsl
index be0afc9..0412722 100644
--- a/Documentation/manpage-normal.xsl
+++ b/Documentation/manpage-normal.xsl
@@ -9,17 +9,4 @@
<xsl:param name="git.docbook.backslash">\</xsl:param>
<xsl:param name="git.docbook.dot" >.</xsl:param>
-<!-- attempt to work around spurious .sp at the tail of the line
- that docbook stylesheets seem to add -->
-<xsl:template match="simpara">
- <xsl:variable name="content">
- <xsl:apply-templates/>
- </xsl:variable>
- <xsl:value-of select="normalize-space($content)"/>
- <xsl:if test="not(ancestor::authorblurb) and
- not(ancestor::personblurb)">
- <xsl:text> </xsl:text>
- </xsl:if>
-</xsl:template>
-
</xsl:stylesheet>
--
1.6.2.1.214.ge986c
^ permalink raw reply related
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