* [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
* [PATCH 4/8] Documentation: move quieting params 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>
Move a couple of XSL parameters that act to silence
informational/warning messages generated when running xmlto from
manpage-1.72.xsl to manpage-base.xsl.
Since unused parameters are silently ignored, there is no problem
if some version of docbook-xsl does not know about these
parameters. The only problem might be if a version of docbook-xsl
uses the parameters for alternate functionality. Since both
parameters have fairly specific names such a situation is
unlikely.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
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.
---
Documentation/manpage-1.72.xsl | 4 ----
Documentation/manpage-base.xsl | 4 ++++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/manpage-1.72.xsl b/Documentation/manpage-1.72.xsl
index 06d4485..8b815cd 100644
--- a/Documentation/manpage-1.72.xsl
+++ b/Documentation/manpage-1.72.xsl
@@ -10,8 +10,4 @@
<xsl:param name="git.docbook.backslash">▓</xsl:param>
<xsl:param name="git.docbook.dot" >⌂</xsl:param>
-<!-- these params silence some output from xmlto -->
-<xsl:param name="man.output.quietly" select="1"/>
-<xsl:param name="refentry.meta.get.quietly" select="1"/>
-
</xsl:stylesheet>
diff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl
index 6d3eb19..a264fa6 100644
--- a/Documentation/manpage-base.xsl
+++ b/Documentation/manpage-base.xsl
@@ -3,6 +3,10 @@
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
+<!-- these params silence some output from xmlto -->
+<xsl:param name="man.output.quietly" select="1"/>
+<xsl:param name="refentry.meta.get.quietly" select="1"/>
+
<!-- convert asciidoc callouts to man page format;
git.docbook.backslash and git.docbook.dot params
must be supplied by another XSL file or other means -->
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* [PATCH 3/8] Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff
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>
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.
Also, document which make variables should be set for various
versions of asciidoc and docbook-xsl.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
This has no behavior changes for existing uses (make
DOCBOOK_XSL_172=Yes), but it enables new functionality
(ASCIIDOC_NO_ROFF=Yes) by divorcing the roff-avoiding parts of
asciidoc.conf from the label docbook-xsl-172.
I like the idea of including "tested with asciidoc/docbook-xsl
version info" in the commit message. It would have been very
helpful if all the previous commits to the core documentation
generation infrastructure carried such information.
---
Documentation/Makefile | 29 ++++++++++++++++++++++++++++-
Documentation/asciidoc.conf | 8 ++++----
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 1b5ff36..11b26aa 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -59,12 +59,39 @@ endif
-include ../config.mak.autogen
-include ../config.mak
+#
+# For asciidoc ...
+# -7.1.2, no extra settings are needed.
+# 8.0-, set ASCIIDOC8.
+#
+
+#
+# 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
+#
+
+#
+# If you had been using DOCBOOK_XSL_172 in an attempt to get rid
+# of 'the ".ft C" problem' in your generated manpages, and you
+# instead ended up with weird characters around callouts, try
+# using ASCIIDOC_NO_ROFF instead (it works fine with ASCIIDOC8).
+#
+
ifdef ASCIIDOC8
ASCIIDOC_EXTRA += -a asciidoc7compatible
endif
ifdef DOCBOOK_XSL_172
-ASCIIDOC_EXTRA += -a docbook-xsl-172
+ASCIIDOC_EXTRA += -a git-asciidoc-no-roff
MANPAGE_XSL = manpage-1.72.xsl
+else
+ ifdef ASCIIDOC_NO_ROFF
+ # docbook-xsl after 1.72 needs the regular XSL, but will not
+ # pass-thru raw roff codes from asciidoc.conf, so turn them off.
+ ASCIIDOC_EXTRA += -a git-asciidoc-no-roff
+ endif
endif
#
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 1e735df..ce1b175 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -27,7 +27,7 @@ ifdef::backend-docbook[]
endif::backend-docbook[]
ifdef::backend-docbook[]
-ifndef::docbook-xsl-172[]
+ifndef::git-asciidoc-no-roff[]
# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
# v1.72 breaks with this because it replaces dots not in roff requests.
[listingblock]
@@ -42,9 +42,9 @@ ifdef::doctype-manpage[]
endif::doctype-manpage[]
</literallayout>
{title#}</example>
-endif::docbook-xsl-172[]
+endif::git-asciidoc-no-roff[]
-ifdef::docbook-xsl-172[]
+ifdef::git-asciidoc-no-roff[]
ifdef::doctype-manpage[]
# The following two small workarounds insert a simple paragraph after screen
[listingblock]
@@ -62,7 +62,7 @@ ifdef::doctype-manpage[]
</literallayout><simpara></simpara>
{title#}</para></formalpara>
endif::doctype-manpage[]
-endif::docbook-xsl-172[]
+endif::git-asciidoc-no-roff[]
endif::backend-docbook[]
ifdef::doctype-manpage[]
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* [PATCH 2/8] Documentation: use parametrized manpage-base.xsl with manpage-{1.72,normal}.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>
Parametrize the backslash and dot characters that are used to
generate roff control sequences in manpage-base.xsl.
The code reuse is achieved through the Makefile's invocation of
xmlto, where the -base and either -normal or -1.72 "modules" are
combined to render the manpages. xmlto's module system works by
constructing a temporary XSLT stylesheet that <xsl:import>s the
main docbook-xsl file and then <xsl:includes> all the modules
specified on the command line. Because of a technical detail of
XSLT (<http://www.w3.org/TR/xslt#top-level-variables>), we need
to be sure that each param is bound only once across all the
modules that will be used in a single xmlto invocation.
The initial implementation used an explicit <xsl:import> to
achieve a layering effect that allowed default param values and
override param values. That worked fine until one of the final
features of this series needed to supply override param values
via the --stringparam option of xmlto. It turns out that
--stringparam is broken in all but the pre-release version of
xmlto. Since xmlto is a shell script the patch to fix it is
simple enough, but I instead opted to use xmlto's "module"
functionality to achieve the XSLT stylesheet reuse.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
Still no change in behavior. Just refactoring here.
---
Documentation/Makefile | 2 +-
Documentation/manpage-1.72.xsl | 28 +++++++++++---------------
Documentation/manpage-base.xsl | 39 +++++++++++++++++++------------------
Documentation/manpage-normal.xsl | 29 +++++++++++----------------
4 files changed, 45 insertions(+), 53 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e1562e3..1b5ff36 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -165,7 +165,7 @@ $(MAN_HTML): %.html : %.txt
%.1 %.5 %.7 : %.xml
$(RM) $@
- xmlto -m $(MANPAGE_XSL) man $<
+ xmlto -m $(MANPAGE_XSL) -m manpage-base.xsl man $<
%.xml : %.txt
$(RM) $@+ $@
diff --git a/Documentation/manpage-1.72.xsl b/Documentation/manpage-1.72.xsl
index 4065a3a..06d4485 100644
--- a/Documentation/manpage-1.72.xsl
+++ b/Documentation/manpage-1.72.xsl
@@ -1,21 +1,17 @@
-<!-- Based on callouts.xsl. Fixes man page callouts for DocBook 1.72 XSL -->
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+<!-- 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 -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+<!-- these are the special values for the roff control characters
+ needed for docbook-xsl 1.72.0 -->
+<xsl:param name="git.docbook.backslash">▓</xsl:param>
+<xsl:param name="git.docbook.dot" >⌂</xsl:param>
+
+<!-- these params silence some output from xmlto -->
<xsl:param name="man.output.quietly" select="1"/>
<xsl:param name="refentry.meta.get.quietly" select="1"/>
-<xsl:template match="co">
- <xsl:value-of select="concat('▓fB(',substring-after(@id,'-'),')▓fR')"/>
-</xsl:template>
-<xsl:template match="calloutlist">
- <xsl:text>⌂sp </xsl:text>
- <xsl:apply-templates/>
- <xsl:text> </xsl:text>
-</xsl:template>
-<xsl:template match="callout">
- <xsl:value-of select="concat('▓fB',substring-after(@arearefs,'-'),'. ▓fR')"/>
- <xsl:apply-templates/>
- <xsl:text>⌂br </xsl:text>
-</xsl:template>
-
</xsl:stylesheet>
diff --git a/Documentation/manpage-base.xsl b/Documentation/manpage-base.xsl
index 6a361a2..6d3eb19 100644
--- a/Documentation/manpage-base.xsl
+++ b/Documentation/manpage-base.xsl
@@ -1,30 +1,31 @@
-<!-- callout.xsl: converts asciidoc callouts to man page format -->
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+<!-- manpage-base.xsl:
+ special formatting for manpages rendered from asciidoc+docbook -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+
+<!-- convert asciidoc callouts to man page format;
+ git.docbook.backslash and git.docbook.dot params
+ must be supplied by another XSL file or other means -->
<xsl:template match="co">
- <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
+ <xsl:value-of select="concat(
+ $git.docbook.backslash,'fB(',
+ substring-after(@id,'-'),')',
+ $git.docbook.backslash,'fR')"/>
</xsl:template>
<xsl:template match="calloutlist">
- <xsl:text>.sp </xsl:text>
+ <xsl:value-of select="$git.docbook.dot"/>
+ <xsl:text>sp </xsl:text>
<xsl:apply-templates/>
<xsl:text> </xsl:text>
</xsl:template>
<xsl:template match="callout">
- <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
+ <xsl:value-of select="concat(
+ $git.docbook.backslash,'fB',
+ substring-after(@arearefs,'-'),
+ '. ',$git.docbook.backslash,'fR')"/>
<xsl:apply-templates/>
- <xsl:text>.br </xsl:text>
-</xsl:template>
-
-<!-- sorry, this is not about callouts, but attempts to work around
- spurious .sp at the tail of the line 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:value-of select="$git.docbook.dot"/>
+ <xsl:text>br </xsl:text>
</xsl:template>
</xsl:stylesheet>
diff --git a/Documentation/manpage-normal.xsl b/Documentation/manpage-normal.xsl
index 6a361a2..be0afc9 100644
--- a/Documentation/manpage-normal.xsl
+++ b/Documentation/manpage-normal.xsl
@@ -1,21 +1,16 @@
-<!-- callout.xsl: converts asciidoc callouts to man page format -->
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
-<xsl:template match="co">
- <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
-</xsl:template>
-<xsl:template match="calloutlist">
- <xsl:text>.sp </xsl:text>
- <xsl:apply-templates/>
- <xsl:text> </xsl:text>
-</xsl:template>
-<xsl:template match="callout">
- <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
- <xsl:apply-templates/>
- <xsl:text>.br </xsl:text>
-</xsl:template>
+<!-- manpage-normal.xsl:
+ special settings for manpages rendered from asciidoc+docbook
+ must be used with manpage-base.xsl
+ handles anything we want to keep away from docbook-xsl 1.72.0 -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+
+<!-- these are the normal values for the roff control characters -->
+<xsl:param name="git.docbook.backslash">\</xsl:param>
+<xsl:param name="git.docbook.dot" >.</xsl:param>
-<!-- sorry, this is not about callouts, but attempts to work around
- spurious .sp at the tail of the line docbook stylesheets seem to add -->
+<!-- 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/>
--
1.6.2.1.214.ge986c
^ permalink raw reply related
* [PATCH 0/8] Documentation: XSLT/asciidoc.conf cleanup; tty literals
From: Chris Johnsen @ 2009-03-24 8:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
I had a go at wrangling with the documentation generation tools
to fix a couple of issues that I had noticed.
First, I could never get reasonable output for generated
manpages. I have asciidoc 8.3.1 and docbook-xsl 1.74.0 on my
system. They chew through the documentation OK, but I was never
sure which flags I should use with them.
ASCIIDOC8 never seemed to do much (I was probably not looking in
the right places), but I decided to leave it enabled since it is
entirely outside the scope of the git code/configuration.
The other variable was DOCBOOK_XSL_172, and no matter which way I
turned it, I always got flawed output. If I set it, I would get
funky characters in the callout sections. If I unset it, I would
get ".ft C" and ".ft" bracketing literal blocks.
Second, the inline literal text of both the official and my
generated manpages was indistinguishable from the surrounding
text when viewing manpages in a terminal. It turns out the
official manpages end up with no markup for inline literal
text. The ones I generated did have some markup, but it was
flagged as monospace text, which is not all that distinguishable
from the normal, roman text when viewing through a terminal.
So I set about trying to solve these problems along with the
meta-problem of code duplication between callouts.xsl and
manpage-1.72.xsl.
The following series is my attempt to
eliminate the XSLT code duplication,
tease apart the uses of the "1.72" label that apply only to
docbook-xsl 1.72 and those that also apply to some other
versions of docbook-xsl,
unify some of the items that look like they were applied to
only one side of various "1.72" configurations but still
seemed applicable to the other,
fix a mostly unrelated, small, latent bug in asciidoc.conf,
and provide an option to differentiate inline literal text when
viewed on a terminal.
Documentation/Makefile | 37 ++++++++++++++++++++++--
Documentation/asciidoc.conf | 15 +++++----
Documentation/callouts.xsl | 30 --------------------
Documentation/manpage-1.72.xsl | 28 ++++++------------
Documentation/manpage-base.xsl | 48 ++++++++++++++++++++++++++++++++
Documentation/manpage-bold-literal.xsl | 17 +++++++++++
Documentation/manpage-normal.xsl | 12 ++++++++
7 files changed, 129 insertions(+), 58 deletions(-)
--
Chris
^ permalink raw reply
* [PATCH 1/8] Documentation: move callouts.xsl to manpage-{base,normal}.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>
Each of manpage-base.xsl and manpage-normal.xsl gets a copy of
the contents of callouts.xsl and the original is removed. The
Makefile is adjusted to refer to manpage-normal.xsl instead of
callouts.xsl. manpage-base.xsl will be later made into a common
base for -normal and -1.72.
Testing done with asciidoc 8.3.1 and docbook-xsl 1.74.0.
Signed-off-by: Chris Johnsen <chris_johnsen@pobox.com>
---
This duplication is in preparation for refactoring. It should
make it easier to keep track of the source of the various XSL
constructs while reviewing.
---
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
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/callouts.xsl
deleted file mode 100644
index 6a361a2..0000000
--- a/Documentation/callouts.xsl
+++ /dev/null
@@ -1,30 +0,0 @@
-<!-- callout.xsl: converts asciidoc callouts to man page format -->
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
-<xsl:template match="co">
- <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
-</xsl:template>
-<xsl:template match="calloutlist">
- <xsl:text>.sp </xsl:text>
- <xsl:apply-templates/>
- <xsl:text> </xsl:text>
-</xsl:template>
-<xsl:template match="callout">
- <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
- <xsl:apply-templates/>
- <xsl:text>.br </xsl:text>
-</xsl:template>
-
-<!-- sorry, this is not about callouts, but attempts to work around
- spurious .sp at the tail of the line 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-base.xsl b/Documentation/manpage-base.xsl
new file mode 100644
index 0000000..6a361a2
--- /dev/null
+++ b/Documentation/manpage-base.xsl
@@ -0,0 +1,30 @@
+<!-- callout.xsl: converts asciidoc callouts to man page format -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+<xsl:template match="co">
+ <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
+</xsl:template>
+<xsl:template match="calloutlist">
+ <xsl:text>.sp </xsl:text>
+ <xsl:apply-templates/>
+ <xsl:text> </xsl:text>
+</xsl:template>
+<xsl:template match="callout">
+ <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
+ <xsl:apply-templates/>
+ <xsl:text>.br </xsl:text>
+</xsl:template>
+
+<!-- sorry, this is not about callouts, but attempts to work around
+ spurious .sp at the tail of the line 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
new file mode 100644
index 0000000..6a361a2
--- /dev/null
+++ b/Documentation/manpage-normal.xsl
@@ -0,0 +1,30 @@
+<!-- callout.xsl: converts asciidoc callouts to man page format -->
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
+<xsl:template match="co">
+ <xsl:value-of select="concat('\fB(',substring-after(@id,'-'),')\fR')"/>
+</xsl:template>
+<xsl:template match="calloutlist">
+ <xsl:text>.sp </xsl:text>
+ <xsl:apply-templates/>
+ <xsl:text> </xsl:text>
+</xsl:template>
+<xsl:template match="callout">
+ <xsl:value-of select="concat('\fB',substring-after(@arearefs,'-'),'. \fR')"/>
+ <xsl:apply-templates/>
+ <xsl:text>.br </xsl:text>
+</xsl:template>
+
+<!-- sorry, this is not about callouts, but attempts to work around
+ spurious .sp at the tail of the line 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
* Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit
From: Guennadi Liakhovetski @ 2009-03-24 8:02 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090324075424.GC32400@coredump.intra.peff.net>
On Tue, 24 Mar 2009, Jeff King wrote:
> On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:
>
> > mkdir x
> > cd x
> > git-init
> > echo hi > greating
> > git-commit -a
> > git-format-patch -1
> >
> > produces a 0-byte long patch. git-format-patch HEAD^ produces an error,
> > whereas with more than one commit it produces tha last patch. Yes, I know
> > about "--root" and that it does allow to extract the very first commit.
>
> What version of git are you using? I believe the 0-byte diff has been
> fixed since git 1.6.1.1.
Mine is still 1.5.4, if it's already fixed in the meantime - all the
better!
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
^ permalink raw reply
* Re: [PATCH 0/9] fprintf(stderr, "warning: ") -> warning() patches
From: Junio C Hamano @ 2009-03-24 8:01 UTC (permalink / raw)
To: Jeff King; +Cc: Miklos Vajna, John Tapsell, Git Mailing List
In-Reply-To: <20090324073513.GA32400@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Mar 24, 2009 at 02:09:08AM +0100, Miklos Vajna wrote:
>
>> Okay, here it is, applies on top of master. All, except the http-push
>> one, applies cleanly on top of next as well here.
>
> I manually scanned the patches and they all look sane to me.
> Thanks.
Thanks; I've done the same and three sets of eyeballs give me a warm fuzzy
feeling ;-)
Applied.
^ permalink raw reply
* Re: [bug?] git-format-patch produces a 0-byte long patch for the first commit
From: Jeff King @ 2009-03-24 7:54 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0903231119110.4871@axis700.grange>
On Mon, Mar 23, 2009 at 11:34:07AM +0100, Guennadi Liakhovetski wrote:
> mkdir x
> cd x
> git-init
> echo hi > greating
> git-commit -a
> git-format-patch -1
>
> produces a 0-byte long patch. git-format-patch HEAD^ produces an error,
> whereas with more than one commit it produces tha last patch. Yes, I know
> about "--root" and that it does allow to extract the very first commit.
What version of git are you using? I believe the 0-byte diff has been
fixed since git 1.6.1.1.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 2/8] docbook: improve css style
From: Felipe Contreras @ 2009-03-24 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Jeff King, git
In-Reply-To: <7vwsaf4qqx.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 24, 2009 at 4:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>>> 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 personally also do not like pages that are too colorful. If you can
> convey the same information with smaller number of colors, please try to
> do so. And remember that some people are colour-challenged.
1 more color makes a page 'too colorful'? Keep in mind that we already
are using 2 colors of blue, links by default have yet another color of
blue and visited links have a magenta color.
The color-challenged people would already see that text as italic,
there's no reason for the non-color-challenged people to _not_ take
advantage of being able to distinguish a different color. If you don't
like green, then fine, the other options are a) pick a different color
b) make the text bold.
I think bold is too distracting and a color that is a) hue-similar to
blue and b) closely dark to black, is the best choice: green.
> 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?
But meh, I'll revert it.
> I thought that browsers typically have user control to let you set the
> standard font size and choice independently for proportional, serif, sans
> and mono, and people who want to see typewriter face in smaller font would
> already have set their browser to do so (I don't do so myself because I'd
> rather want to see them in uniform size). I haven't checked your CSS, but
> if you are doing "monospace smaller than usual", aren't you effectively
> (1) doing disservice to people like me, and (2) doing disservice to people
> who do want smaller monospace and configured their browser already (the
> outcome would be doubly smaller, which may become too small)?
By that logic no web site should ever choose a different font-size
than 'normal', and of course they do.
--
Felipe Contreras
^ permalink raw reply
* Re: checkout/update boiler plate for --filter-index?
From: Jeff King @ 2009-03-24 7:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Marcel Cary, Git Mailing List
In-Reply-To: <49C889E2.2080208@viscovery.net>
On Tue, Mar 24, 2009 at 08:21:06AM +0100, Johannes Sixt wrote:
> You cannot do that with the index filter because you need actual blob
> contents to operate on, but the index filter doesn't give you an
> opportunity to do that. The tree filter is the right filter to use. But
> you neither need 'git checkout' nor 'git update-index' in the filter -
> filter-branch calls them for you. (Oh, and get rid of that useless use of
> cat.)
Well, you _could_ do it as an index-filter, which has the potential to
be much faster if you are only operating only on a small subset of the
files. But it's much less readable. Something like (totally untested):
git filter-branch --index-filter '
for i in `cat /path/to/files`; do
hash=$(git cat-file :$i |
sed 's/foo/bar/' |
git hash-object -w --stdin)
git update-index --add --cacheinfo 100644 $hash $i
done
'
I'm sure you could do even do it with a constant number of processes per
commit by using update-index --index-info, hash-object --stdin-paths,
and cat-file --batch. But it would probably be even less readable. ;)
Personally, I would probably just do a tree-filter for simplicity unless
the repo size made it prohibitively slow.
-Peff
^ permalink raw reply
* Re: Minimum libCurl version for git
From: Junio C Hamano @ 2009-03-24 7:35 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git list, Daniel Stenberg, Nick Hengeveld, Mike Hommey
In-Reply-To: <e2b179460903230424v1c98d73ci1f41918807fb2d5c@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> writes:
> 2009/3/20 Junio C Hamano <gitster@pobox.com>:
>> We can have these two macro definitions on our side
>>
>> #if curl older than 7.10.8
>> #define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE
>> #endif
>>
>> #if curl older than 7.9.7
>> #define CURLOPT_READDATA CURLOPT_INFILE
>> #endif
>>
>> for backward compatibility, while writing our code to the recent API by
>> using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older
>> curl would not have to suffer a bit.
>
> See? That's why they pay you the big maintainer-bucks... 8-)
The big maintainer-buck is called zero cents. I am only paid with the
freedom to spend 20% of my day-job time on git [*1*].
In any case, "Write to the latest API, support older platforms with
backward compatibility wrapper as necessary" is a good practice employed
by many successful projects, including the kernel, and I think it would
apply here nicely.
>> Mike, I'd say we declare 7.9.3 as the floor and go from there. That's
>> your #3, I think.
>
> Short patch series to follow, though maybe not today.
Thanks.
[Footnote]
*1* ... which is still generous of my employer and NEC, given the current
economic climate, but I wouldn't exactly call that "big bucks" ;-).
^ permalink raw reply
* Re: [PATCH 0/9] fprintf(stderr, "warning: ") -> warning() patches
From: Jeff King @ 2009-03-24 7:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, John Tapsell, Git Mailing List
In-Reply-To: <cover.1237856682.git.vmiklos@frugalware.org>
On Tue, Mar 24, 2009 at 02:09:08AM +0100, Miklos Vajna wrote:
> Okay, here it is, applies on top of master. All, except the http-push
> one, applies cleanly on top of next as well here.
I manually scanned the patches and they all look sane to me.
Thanks.
-Peff
^ permalink raw reply
* Re: checkout/update boiler plate for --filter-index?
From: Johannes Sixt @ 2009-03-24 7:21 UTC (permalink / raw)
To: Marcel Cary; +Cc: Git Mailing List
In-Reply-To: <580660BE-FDAB-4947-B409-1E8D5CBEF8EE@earth.care2.com>
Marcel Cary schrieb:
> I'm trying to do a historical find-and-replace on my code:
>
> git grep -F foo > files
> git filter-branch --index-filter "
> cat `pwd`/files | xargs git checkout --
> cat `pwd`/files | xargs sed -i 's/foo/bar/g; '
> cat `pwd`/files | xargs git update-index --
> " ancestor..HEAD
>
> When I instead use --tree-filter and skip the checkout/update-index, it
> works how I want (but it takes a while...). But when I use
> --index-filter, the resulting history shows the "foo" to "bar" change
> happening *after* new code is added, rather than originally adding "bar".
>
> How can I checkout just a few files and update them to take advantage of
> the speed of index operations?
You cannot do that with the index filter because you need actual blob
contents to operate on, but the index filter doesn't give you an
opportunity to do that. The tree filter is the right filter to use. But
you neither need 'git checkout' nor 'git update-index' in the filter -
filter-branch calls them for you. (Oh, and get rid of that useless use of
cat.)
-- Hannes
^ permalink raw reply
* Re: git svn teething problems - initial clone okay - fetches not working
From: Pascal Obry @ 2009-03-24 6:41 UTC (permalink / raw)
To: Aaron Gray; +Cc: Tim Visher, Git Mailing List
In-Reply-To: <D9560AEA971144C99A0540C08AAFC3D1@HPLAPTOP>
Aaron Gray a écrit :
> Probably. I am getting an error on doing 'git svn rebase' :-
>
> many filenames * : needs update
> update---index --refresh: command returned error: 1
So before the rebase try:
$ git reset --hard HEAD
then
$ git svn rebase
> Could you please give me the command to import the above SVN repository
> so I can redo the thing from scratch.
What you have done (at least described here in this forum) seems correct.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Adding a new file to all git branches
From: Jeff King @ 2009-03-24 6:31 UTC (permalink / raw)
To: Aneesh Bhasin; +Cc: git
In-Reply-To: <f662f0210903232041p6f86b882of7b2d708946ea905@mail.gmail.com>
On Tue, Mar 24, 2009 at 09:11:15AM +0530, Aneesh Bhasin wrote:
> I was wondering if it is possible to add a file to all the branches in
> a repository without individually checking out each branch ?
>
> A possible use-case for such a scenario is say I have a git repository
> with various branches related to different features, versions or
> bug-fixes and I want to be able to add a README file which contains
> instructions/information common to all of those branches as of now
> (but may diverge in future). So, do I have to checkout each branch
> individually to add the same README file to all of them or is there a
> direct/indirect workaround ?
Not really.
You basically have three options:
1. branch a new "README" line of development from some common ancestor
of all branches, add the README, and then merge this new branch into
your other branches
The advantage of this approach is that you could actually keep the
README branch around, making changes to it and merging it back into
your other branches as appropriate.
Of course, you asked about avoiding "checkout", and you will still
have to checkout each branch to do the merge.
2. For a one-off addition of such a README, it is probably simpler to
just use a for loop with checkout:
for i in branch1 branch2 branch3; do
git checkout $i &&
cp /path/to/README . &&
git add README &&
git commit -m 'add README'
done
Which again, obviously does checkout, but at least it's
non-interactive. The biggest downside is that doing a full checkout
between branches might be slow.
3. You could also just iterate over the branches with plumbing, adding
the README to each tree. Something like:
hash=`git hash-object -w /path/to/README`
for i in b1 b2 b3; do
GIT_INDEX_FILE=index.$i; export GIT_INDEX_FILE
git read-tree $i &&
git update-index --add --cacheinfo 100644 $hash README &&
tree=$(git write-tree) &&
parent=$(git rev-parse $i) &&
commit=$(echo added README | git commit-tree $tree -p $parent) &&
git update-ref -m "commit: added README" refs/heads/$i $commit $parent
rm $GIT_INDEX_FILE
sleep 1
done
This is going to be faster, but obviously is much more complicated.
For a one-off addition, I would probably just do (2).
-Peff
^ permalink raw reply
* Re: GIT BUG? GIT occasionally redownloads its entire data set
From: Junio C Hamano @ 2009-03-24 6:02 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: David Howells, git, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <37fcd2780903231953pdfaa679r8a680f64ee692c8d@mail.gmail.com>
Dmitry Potapov <dpotapov@gmail.com> writes:
> On Tue, Mar 24, 2009 at 5:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Rings a bell, anybody?
>
> Maybe this:
> http://article.gmane.org/gmane.comp.version-control.git/75201
>
> It was fixed in Git 1.5.5 if I am not mistaken.
Thanks. Distributed memory works very well ;-)
^ permalink raw reply
* Re: started a cvsps testsuite Was: Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Michael Haggerty @ 2009-03-24 4:50 UTC (permalink / raw)
To: Heiko Voigt
Cc: Michael J Gruber, Junio C Hamano, Heiko Voigt, ydirson, git,
CVSps
In-Reply-To: <20090323181110.GB26678@macbook.lan>
Heiko Voigt wrote:
> I just started a very simple but hopefully effective testsuite to
> collect all the issues we found with cvsps. [...]
>
> Maybe Michael can add his tests as well. You should just need to
> construct the expected cvsps output.
Please note that the cvsps output format itself is not rich enough to
represent all of the information needed, so it is not trivial to
construct the "expected" output. The following is from an email that I
sent to the Mercurial mailing list [1]:
> I spent some time looking into cvsps, and I don't think that its
> output format, let alone the output itself, is suitable for
> industrial-strength conversion from CVS. For example, as far as I
> can tell from my brief investigation:
>
> * log messages are not unambiguously separable from the metadata
>
> * it seems to only allow a single tag per changeset
>
> * it seems to only apply tags to single changesets, whereas in CVS
> files can be added to a tag at different times.
> ...
>
> * it seems to completely ignore a branch tag if no commits were
> ever made on that branch.
>
> * it seems to ignore the effect that a second import to a vendor
> branch has on the main branch.
You might also be interested to know that there has been some work in
the Mercurial project on a Python-based "cvsps". I believe they use
their own version for their cvsimport extension. I don't know how
different their cvsps is from the original.
Michael
[1] http://selenic.com/pipermail/mercurial-devel/2008-February/004975.html
^ permalink raw reply
* Adding a new file to all git branches
From: Aneesh Bhasin @ 2009-03-24 3:41 UTC (permalink / raw)
To: git
Hi,
I was wondering if it is possible to add a file to all the branches in
a repository without individually checking out each branch ?
A possible use-case for such a scenario is say I have a git repository
with various branches related to different features, versions or
bug-fixes and I want to be able to add a README file which contains
instructions/information common to all of those branches as of now
(but may diverge in future). So, do I have to checkout each branch
individually to add the same README file to all of them or is there a
direct/indirect workaround ?
Thanks for your help..
Regards,
Aneesh
^ permalink raw reply
* Re: [RFC/WIP 0/2] Documentation clean-up: git commands
From: Jeff King @ 2009-03-24 3:34 UTC (permalink / raw)
To: Chris Johnsen; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <37FD43AD-E43A-4565-8085-95E606E0B868@pobox.com>
On Mon, Mar 23, 2009 at 06:13:11PM -0500, Chris Johnsen wrote:
> 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
Oh, good, thanks for working on this. I was actually about to start
looking at it tonight.
For the final one, italicized or emphasized text will often end up
underlined in most terminals. Peeking at other manpages led me to the
conclusion that bolding literal text is the most common convention.
-Peff
^ permalink raw reply
* Re: [PATCH] Add warning about known issues to documentation of cvsimport
From: Jeff King @ 2009-03-24 3:14 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git
In-Reply-To: <20090323195304.GC26678@macbook.lan>
On Mon, Mar 23, 2009 at 08:53:05PM +0100, Heiko Voigt wrote:
> The described issues are compiled from the tests by Michael Haggerty and me.
> Because it is not apparent that these can be fixed anytime soon at least warn
> unwary users not to rely on the inbuilt cvsimport to much.
I think this change is good in concept.
> +[[issues]]
> +ISSUES
> +------
> +Problems related to timestamps:
> +
> + * If timestamps of commits in the cvs repository are not stable enough
> + to be used for ordering commits
> + * If any files were ever "cvs import"ed more than once (e.g., import of
> + more than one vendor release)
> + * If the timestamp order of different files cross the revision order
> + within the commit matching time window
Reading this, I kept waiting for the "then" to your "if". I think the
implication is "your import will be incorrect". But it would be nice to
say _how_, even if it's something as simple as "changes may show up in
the wrong commit, the wrong branch, be omitted" or whatever. Just give a
general idea of what can happen.
Also, this renders somewhat poorly in the manpage version. I get:
<quote>
ISSUES
Problems related to timestamps:
· If timestamps of commits in the cvs repository are not stable
enough to be used for ordering commits
· If any files were ever "cvs import"ed more than once (e.g., import
of more than one vendor release)
· If the timestamp order of different files cross the revision order
within the commit matching time window
Problems related to branches:
· Branches on which no commits have been made are not imported
</quote>
Note the extra blank line between each heading and its list, and the
lack of a blank line between the end of the first list and the heading
of the second. Your source is very readable, so it really is just
asciidoc being silly, but I wonder if there is a way to work around
that.
-Peff
^ permalink raw reply
* [JGit] Mismatch CRC in packed objects from `jgit push`
From: Daniel Cheng @ 2009-03-24 2:53 UTC (permalink / raw)
To: git
Hi list,
When I working with jgit-over-freenet, I found the pack files as
generated by `jgit push` give CRC error in `git fsck` and `git clone`,
but they are perfectly okay if I do a `git unpack-objects` manually.
You can download the pack file here:
http://sdiz.net/temp/pack-fcedfaa7130866c884e208769661360563a3081f.idx
http://sdiz.net/temp/pack-fcedfaa7130866c884e208769661360563a3081f.pack
Here is the diagnose session:
sdiz@sp2:/tmp$ git clone --verbose http://........
[...]
Getting index for pack fcedfaa7130866c884e208769661360563a3081f
Getting pack fcedfaa7130866c884e208769661360563a3081f
which contains f197d4578a1b8ed195981d1e1ad4c390875c353a
error: index CRC mismatch for object
f197d4578a1b8ed195981d1e1ad4c390875c353a from
/tmp/egit-freenet/.git/objects/pack/pack-fcedfaa7130866c884e208769661360563a3081f.pack
at offset 12
error: index CRC mismatch for object
0b2cb180fef969e0da259765564f9bf8bcd8cf25 from
/tmp/egit-freenet/.git/objects/pack/pack-fcedfaa7130866c884e208769661360563a3081f.pack
at offset 183
error: index CRC mismatch for object
d88f5a430841925629c30199e666473d201bdf5a from
/tmp/egit-freenet/.git/objects/pack/pack-fcedfaa7130866c884e208769661360563a3081f.pack
at offset 379
error: index CRC mismatch for object
40d3204c679fc5d25281331b981d968016030930 from
/tmp/egit-freenet/.git/objects/pack/pack-fcedfaa7130866c884e208769661360563a3081f.pack
at offset 558
[...]
sdiz@sp2:/tmp$ git --version
git version 1.6.2
// Using the pack file directly seems okay, but fsck give the CRC error :
sdiz@sp2:/tmp/z$ git init
Initialized empty Git repository in /tmp/z/.git/
sdiz@sp2:/tmp/z$ cp ../pack-* .git/objects/pack/
sdiz@sp2:/tmp/z$ git checkout f197d4578a1b8ed195981d1e1ad4c390875c353a
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of f197d4578a1b8ed195981d1e1ad4c390875c353a.
Note: moving to "f197d4578a1b8ed195981d1e1ad4c390875c353a" which isn't
a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at f197d45... Instruction for cloning with git+fproxy
sdiz@sp2:/tmp/z$ ls
0x7494252.asc activelink.png freenet-bunny.svg index.html jgit
jgit.jar jgit_src.zip
sdiz@sp2:/tmp/z$
sdiz@sp2:/tmp/z$ git fsck f197d4578a1b8ed195981d1e1ad4c390875c353a
error: index CRC mismatch for object
f197d4578a1b8ed195981d1e1ad4c390875c353a from
.git/objects/pack/pack-fcedfaa7130866c884e208769661360563a3081f.pack
at offset 12
error: index CRC mismatch for object
0b2cb180fef969e0da259765564f9bf8bcd8cf25 from
.git/objects/pack/pack-fcedfaa7130866c884e208769661360563a3081f.pack
at offset 183
error: index CRC mismatch for object
d88f5a430841925629c30199e666473d201bdf5a from
.git/objects/pack/pack-fcedfaa7130866c884e208769661360563a3081f.pack
at offset 379
[...]
// unpack the objects manually seems to fix the issue
sdiz@sp2:/tmp/z$ rm -f .git/objects/*/*
sdiz@sp2:/tmp/z$ git unpack-objects --strict -r <
../pack-fcedfaa7130866c884e208769661360563a3081f.pack
Unpacking objects: 100% (26/26), done.
sdiz@sp2:/tmp/z$ git fsck --full f197d4578a1b8ed195981d1e1a
sdiz@sp2:/tmp/z$
// diff'ing the checkout with the original repository is also okay
sdiz@sp2:/tmp/z$ diff -Nau ~/build/egit/ .
Common subdirectories: /home/sdiz/build/egit/.git and ./.git
sdiz@sp2:/tmp/z$
// Fsck'ing in original repository is perfectly okay:
sdiz@sp2:~/build/egit$ git fsck --full f197d4
dangling commit 9900ac0df33e046c2f3f77ad8e084d535d3c023d
dangling commit 2e12ce6571923190124e86cc6b877ccb3ace9219
dangling commit f8150b71a352176f672270ffced6958682b215f3
dangling commit 101ae6bff9ca647c7c8297556314757162fbc2f2
[..]
^ permalink raw reply
* Re: GIT BUG? GIT occasionally redownloads its entire data set
From: Dmitry Potapov @ 2009-03-24 2:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Howells, git, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <7vskl34qc9.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 24, 2009 at 5:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Rings a bell, anybody?
Maybe this:
http://article.gmane.org/gmane.comp.version-control.git/75201
It was fixed in Git 1.5.5 if I am not mistaken.
Dmitry
^ permalink raw reply
* Re: GIT BUG? GIT occasionally redownloads its entire data set
From: Junio C Hamano @ 2009-03-24 2:17 UTC (permalink / raw)
To: David Howells; +Cc: git, Daniel Barkalow, Shawn O. Pearce
In-Reply-To: <28707.1237855543@redhat.com>
David Howells <dhowells@redhat.com> writes:
> to v2.6.29. I've attached the command output for reference.
Version of git used, and the .git/config ([remote "origin"] section)?
> warthog>git-pull
> remote: Counting objects: 447, done.
> remote: Compressing objects: 100% (57/57), done.
> remote: Total 266 (delta 216), reused 254 (delta 207)
> Receiving objects: 100% (266/266), 37.94 KiB, done.
> Resolving deltas: 100% (216/216), completed with 105 local objects.
> warning: no common commits
> remote: Counting objects: 1075436, done.
> remote: Compressing objects: 100% (176743/176743), done.
> remote: Total 1075436 (delta 896164), reused 1072243 (delta 893708)
> Receiving objects: 100% (1075436/1075436), 260.71 MiB | 307 KiB/s, done.
> Resolving deltas: 100% (896164/896164), done.
>>From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
This is intereseting because it shows that two separate transfer happened
back to back, which I do not think is what recent git does.
We used to first grab the objects reachable from primary refs (presumably
[remote "origin"] fetch = refs/heads/*:refs/remotes/origin/*) and then
turned around to ask for tags that possibly point at commits we freshly
obtained during the first transfer (i.e. the ones reachable from the tip
of "master"). In such an ancient version I vaguely recall some bugs fixed
before we stopped doing this two-stage transfer altogether, but I do not
recall offhand if a bug that loses track of what it just downloaded (which
is what your description suggests) was among them.
Rings a bell, anybody?
^ permalink raw reply
* Re: .gitk should created hidden in windows
From: Johannes Schindelin @ 2009-03-24 2:14 UTC (permalink / raw)
To: John Tapsell; +Cc: Paul Mackerras, Steve Wagner, git
In-Reply-To: <43d8ce650903231908y54bb1c34t45a78f218b2ccd9f@mail.gmail.com>
Hi,
On Tue, 24 Mar 2009, John Tapsell wrote:
> How about making all files beginning with . hidden? .gitignore for
> example
Uhm.
Did you miss that this patch was about gitk, not git.git?
Ciao,
Dscho
^ 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