* Re: [PATCH] avoid asciidoc warning in git-cvsserver.txt
From: Martin Langhoff @ 2006-03-05 19:22 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060305121131.GA20503@craic.sysops.org>
On 3/6/06, Francis Daly <francis@daoine.org> wrote:
> Oops, I missed
>
> Subject: [PATCH] cvsserver: updated documentation
>
> which makes this one redundant.
Thanks anyway to you and Mark for the fixes. Seems we were all working
at the same time on the file!
cheers,
martin
^ permalink raw reply
* Re: [PATCH] contrib/emacs/Makefile: Provide tool for byte-compiling files.
From: Junio C Hamano @ 2006-03-05 19:28 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, Mark Wooding
In-Reply-To: <20060305161431.23622.20032.stgit@metalzone.distorted.org.uk>
Alexandre, this looks good to me, so I'll be applying it.
-jc
Mark Wooding <mdw@distorted.org.uk> writes:
> From: Mark Wooding <mdw@distorted.org.uk>
>
> Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
> ---
>
> contrib/emacs/.gitignore | 1 +
> contrib/emacs/Makefile | 20 ++++++++++++++++++++
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/emacs/.gitignore b/contrib/emacs/.gitignore
> new file mode 100644
> index 0000000..c531d98
> --- /dev/null
> +++ b/contrib/emacs/.gitignore
> @@ -0,0 +1 @@
> +*.elc
> diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
> new file mode 100644
> index 0000000..d3619db
> --- /dev/null
> +++ b/contrib/emacs/Makefile
> @@ -0,0 +1,20 @@
> +## Build and install stuff
> +
> +EMACS = emacs
> +
> +ELC = git.elc vc-git.elc
> +INSTALL = install
> +INSTALL_ELC = $(INSTALL) -m 644
> +prefix = $(HOME)
> +emacsdir = $(prefix)/share/emacs/site-lisp
> +
> +all: $(ELC)
> +
> +install: all
> + $(INSTALL) -d $(emacsdir)
> + $(INSTALL_ELC) $(ELC) $(emacsdir)
> +
> +%.elc: %.el
> + $(EMACS) --batch --eval '(byte-compile-file "$<")'
> +
> +clean:; rm -f $(ELC)
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-05 19:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603051027400.13139@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Actually, thinking more about it, I think we could get rid of SHOWN.
>
> We only ever insert a commit _once_ onto the list, using the SEEN logic,
> so we can never pull the same commit off the list more than once. I think
> SHOWN was for merge-order.
>
> But I might be wrong. I was thinking about SHOWN a bit when I did the
> re-organization, but didn't dare to actually touch it, so I left it alone.
I abused SHOWN when I did --objects-edge with
mark_edge_parents_uninteresting modification in
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4, but probably it can be
modified to use SEEN.
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-03-05 19:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603051027400.13139@g5.osdl.org>
I was going through 'whatchanged rev-list.c' but was half-way
when I sent the previous message. -S'UNINTERESTING|SHOWN' found
this one.
51b1e1713b1ed8e962e994cd0850ea439ad8c3de
Author: Jon Seymour <jon.seymour@gmail.com>
Date: Mon Jun 20 12:29:38 2005 +1000
[PATCH] Prevent git-rev-list without --merge-order producing
dupicates in output
If b is reachable from a, then:
git-rev-list a b
argument would print one of the commits twice.
This patch fixes that problem. A previous problem fixed it
for the --merge-order switch.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
^ permalink raw reply
* Re: What's in git.git
From: Linus Torvalds @ 2006-03-05 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtf8fzvb.fsf@assigned-by-dhcp.cox.net>
On Sun, 5 Mar 2006, Junio C Hamano wrote:
>
> I abused SHOWN when I did --objects-edge with
> mark_edge_parents_uninteresting modification in
> eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4, but probably it can be
> modified to use SEEN.
Ahh, no. SEEN is different from SHOWN. SHOWN means that we've actually
shown that commit, while SEEN just means that we've added it to the list
(but it might be uninteresting, for example). I think you did exactly the
right thing wrt SHOWN.
That said, the revision list walker should never see a SHOWN commit on the
list, because it is the thing that sets SHOWN as it removes the entry from
the list (and it should never get re-added, due to SEEN).
Linus
^ permalink raw reply
* [PATCH] documentation: add 'see also' sections to git-rm and git-add
From: Jeff Muizelaar @ 2006-03-05 21:18 UTC (permalink / raw)
To: git
Pair up git-add and git-rm by adding a 'see also' section that
references the opposite command to each of their documentation files.
---
Documentation/git-add.txt | 3 +++
Documentation/git-rm.txt | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
aedd49a31816736b244b9f61303e112431eff80c
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 7e29383..5b7c354 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -65,6 +65,9 @@ git-add git-*.sh::
(i.e. you are listing the files explicitly), it does not
add `subdir/git-foo.sh` to the index.
+See Also
+--------
+gitlink:git-rm[1]
Author
------
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 401bfb2..d8a5afa 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -74,6 +74,9 @@ git-rm -f git-*.sh::
shell expand the asterisk (i.e. you are listing the files
explicitly), it does not remove `subdir/git-foo.sh`.
+See Also
+--------
+gitlink:git-add[1]
Author
------
--
1.2.4.g8bc6
^ permalink raw reply related
* Re: [PATCH] git-blame: Make the output human readable
From: Junio C Hamano @ 2006-03-05 21:28 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, Johannes Schindelin, Ryan Anderson
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> I find the first format easier to read since everything is aligned (we
> always output 15 characters for the committer's name padded with
> spaces if necessary and the line numbers are padded appropriately). It
> also takes up less space on screen since it doesn't use tabs.
Careful. The convention for names is to encode them in UTF-8,
so if you mean 15 "characters" that might be OK but if it can
truncate in the middle of a multibyte sequence of UTF-8 encoded
single character it is a no-no.
We are talking about "casual" aligning, so I would not bring up
"proportional fonts", but even on a monospace terminal and
line-printer output, there still is the issue of byte count not
matching columns. In an i18nized environment, aligning columns
by counting bytes is a lost battle.
In any case, please make sure you do not chop a character in the
middle at least [*1*].
> We may want to add an output format suitable for scripts too, which
> just lists the SHA1. But I don't think it is much more difficult to
> parse the format above, at least not if you just want the SHA1s.
Fair enough.
> It uses log(3) to compute the number of digits needed to represent the
> last line number. It is probably better to this some other way
> though...
Yup.
[Footnote]
*1* I was kind of impressed that Linus was careful about this
issue when I saw the commit log chopping is only done at line
boundaries. A very careful coder would have chopped the last
line in the middle at character boundary, but if you do not want
to bother that much, chopping at line boundary is better than
chopping the last line in the middle of a character ;-).
^ permalink raw reply
* any problems with new branch of gitk?
From: Paul Mackerras @ 2006-03-05 22:09 UTC (permalink / raw)
To: git
I'm planning to pull the `new' branch of the gitk repository into the
master branch, making the new version of gitk the standard version
that will go into the git.git repository. As far as I know the new
version does everything the old version does. Does anyone know of any
problems with the new gitk that weren't in the old one?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] git-blame: Kill warning "print_map defined but not used"
From: Junio C Hamano @ 2006-03-05 22:45 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.64.0603051054330.13139@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> - you should use "-u -U 0" instead of "-u0" to avoid warnings from some
> versions of GNU diff
One liner here.
> - Please default to HEAD so that you don't need to say it.
Fredrik's latest patch already does.
-- >8 --
Subject: [PATCH] blame: avoid "diff -u0".
As Linus suggests, use "diff -u -U 0" instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
blame.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
1f7d9585190c22a4c019487444d9e461e08baa0e
diff --git a/blame.c b/blame.c
index a3a8ddc..141e4c6 100644
--- a/blame.c
+++ b/blame.c
@@ -92,7 +92,7 @@ static struct patch *get_patch(struct co
die("write failed: %s", strerror(errno));
close(fd);
- sprintf(diff_cmd, "diff -u0 %s %s", tmp_path1, tmp_path2);
+ sprintf(diff_cmd, "diff -u -U 0 %s %s", tmp_path1, tmp_path2);
fin = popen(diff_cmd, "r");
if (!fin)
die("popen failed: %s", strerror(errno));
--
1.2.4.gee5c7
^ permalink raw reply related
* [PATCH] blame: avoid -lm by not using log().
From: Junio C Hamano @ 2006-03-05 22:46 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen, Johannes Schindelin
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
... as suggested on the list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 4 ----
blame.c | 6 ++++--
2 files changed, 4 insertions(+), 6 deletions(-)
e0539773df17e5f8410850b8ffcfe8d2fa14ab7a
diff --git a/Makefile b/Makefile
index eb1887d..b6d8804 100644
--- a/Makefile
+++ b/Makefile
@@ -534,10 +534,6 @@ git-rev-list$X: rev-list.o $(LIB_FILE)
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(OPENSSL_LIBSSL)
-git-blame$X: blame.o $(LIB_FILE)
- $(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
- $(LIBS) -lm
-
init-db.o: init-db.c
$(CC) -c $(ALL_CFLAGS) \
-DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $*.c
diff --git a/blame.c b/blame.c
index 168b1f5..59146fa 100644
--- a/blame.c
+++ b/blame.c
@@ -589,7 +589,7 @@ int main(int argc, const char **argv)
usage(blame_usage);
else if(!strcmp(argv[i], "-l") ||
!strcmp(argv[i], "--long")) {
- sha1_len = 20;
+ sha1_len = 40;
continue;
} else if(!strcmp(argv[i], "-c") ||
!strcmp(argv[i], "--compability")) {
@@ -651,7 +651,9 @@ int main(int argc, const char **argv)
process_commits(&rev, filename, &initial);
buf = blame_contents;
- max_digits = 1 + log(num_blame_lines+1)/log(10);
+ for (max_digits = 1, i = 10; i <= num_blame_lines; max_digits++)
+ i *= 10;
+
for (i = 0; i < num_blame_lines; i++) {
struct commit *c = blame_lines[i];
if (!c)
--
1.2.4.gee5c7
^ permalink raw reply related
* [PATCH] blame and annotate: show localtime with timezone.
From: Junio C Hamano @ 2006-03-05 22:48 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen, Ryan Anderson
In-Reply-To: <20060305123800.GD23448@c165.ib.student.liu.se>
Earlier they showed gmtime and timezone, which was inconsistent
with the way our commits and tags are pretty-printed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
blame.c | 15 ++++++++++++---
git-annotate.perl | 8 +++++++-
2 files changed, 19 insertions(+), 4 deletions(-)
e29f298a17ee898fd0d191d448ba4fc202175896
diff --git a/blame.c b/blame.c
index 59146fa..a3a8ddc 100644
--- a/blame.c
+++ b/blame.c
@@ -550,13 +550,22 @@ static void get_commit_info(struct commi
*tmp = 0;
}
-char* format_time(unsigned long time, const char* tz)
+static const char* format_time(unsigned long time, const char* tz_str)
{
static char time_buf[128];
time_t t = time;
+ int minutes, tz;
+ struct tm *tm;
- strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", gmtime(&t));
- strcat(time_buf, tz);
+ tz = atoi(tz_str);
+ minutes = tz < 0 ? -tz : tz;
+ minutes = (minutes / 100)*60 + (minutes % 100);
+ minutes = tz < 0 ? -minutes : minutes;
+ t = time + minutes * 60;
+ tm = gmtime(&t);
+
+ strftime(time_buf, sizeof(time_buf), "%Y-%m-%d %H:%M:%S ", tm);
+ strcat(time_buf, tz_str);
return time_buf;
}
diff --git a/git-annotate.perl b/git-annotate.perl
index d93ee19..b113def 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -418,7 +418,13 @@ sub format_date {
return $_[0];
}
my ($timestamp, $timezone) = split(' ', $_[0]);
- return strftime("%Y-%m-%d %H:%M:%S " . $timezone, gmtime($timestamp));
+ my $minutes = abs($timezone);
+ $minutes = int($minutes / 100) * 60 + ($minutes % 100);
+ if ($timezone < 0) {
+ $minutes = -$minutes;
+ }
+ my $t = $timestamp + $minutes * 60;
+ return strftime("%Y-%m-%d %H:%M:%S " . $timezone, gmtime($t));
}
# Copied from git-send-email.perl - We need a Git.pm module..
--
1.2.4.gee5c7
^ permalink raw reply related
* Re: any problems with new branch of gitk?
From: A Large Angry SCM @ 2006-03-05 23:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17419.24973.402408.237865@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> I'm planning to pull the `new' branch of the gitk repository into the
> master branch, making the new version of gitk the standard version
> that will go into the git.git repository. As far as I know the new
> version does everything the old version does. Does anyone know of any
> problems with the new gitk that weren't in the old one?
I don't know if the old version has this problem but the new version
does not have a "busy" pointer while it's waiting for a merge diff. Take
a look at the ACPI mega(octo)pus merge that happened in January.
^ permalink raw reply
* [PATCH] Tweak asciidoc output to work with broken docbook-xsl
From: Francis Daly @ 2006-03-05 23:13 UTC (permalink / raw)
To: git
docbook-xsl v1.68 incorrectly converts "<screen>" from docbook to
manpage by not rendering it verbatim. v1.69 handles it correctly, but
not many current popular distributions ship with it.
asciidoc by default converts "listingblock" to "<screen>". This change
causes asciidoc in git to convert "listingblock" to "<literallayout>", which
both old and new docbook-xsl handle correctly.
The difference can be seen in any manpage which includes a multi-line
example, such as git-branch.
---
This one may want some consideration, because it involves changing how
git interacts with asciidoc in order to make up for how an older version
of docbook-xsl is broken. Clear?
What version of docbook-xsl are people who make git manpages using? If
it's not 1.69, the manpages (at least, those with multi-line examples)
display incorrectly. Many current popular distributions seem to be using
version 1.68.
http://www.kernel.org/pub/software/scm/git/RPMS/x86_64/git-core-1.2.4-1.x86_64.rpm
ftp://ftp.kddlabs.co.jp/pub/Linux/packages/fedora/extras/4/i386/git-core-1.2.4-1.fc4.i386.rpm
(found on pbone, with "redhat/" removed from url; for Fedora 4)
The 1.2.1 packages linked from http://packages.debian.org/unstable/devel/git-core
all show the errors.
ftp://ftp.kddlabs.co.jp/pub/Linux/packages/fedora/extras/development/i386/git-core-1.2.4-1.fc5.i386.rpm
(found on pbone, with "redhat/" removed from the url; for Fedora Other,
presumably 5)
is correct.
Clearly the *right* solution is for binary builders to update their
toolchains. Maybe leaving this as-is will be an impetus for them to do so.
Below is a not-right workaround which allows the git manpages render
correctly when built by someone with an old docbook-xsl package.
If this is acceptable, all well and good. If not, I'll contact the package
builders and invite them to upgrade or patch before building new packages.
Documentation/asciidoc.conf | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
1885a1ac69eabd6fa882f4464d3c66303d707566
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index fa0877d..37e9ada 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -23,4 +23,11 @@ ifdef::backend-xhtml11[]
<a href="{target}.html">{target}{0?({0})}</a>
endif::backend-xhtml11[]
+# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
+[listingblock]
+<example><title>{title}</title>
+<literallayout>
+|
+</literallayout>
+{title#}</example>
--
1.2.GIT
--
Francis Daly francis@daoine.org
^ permalink raw reply related
* Re: [PATCH] git-blame: Use the same tests for git-blame as for git-annotate
From: Ryan Anderson @ 2006-03-05 23:32 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, junkio
In-Reply-To: <20060305111334.GB23448@c165.ib.student.liu.se>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
Along these lines, if anyone can pin down the complicated cases that
annotate and blame get differently, adding them as a test would be
*exceedingly* appreciated, even if it makes annotate (or blame) fail for
a bit, it gives us something to work against.
I've been trying to find some time this weekend to dig into why annotate
gets things wrong, but I've been distracted, unfortunately.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* Re: [PATCH] blame: avoid -lm by not using log().
From: Johannes Schindelin @ 2006-03-05 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Fredrik Kuivinen
In-Reply-To: <7vhd6cechf.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Sun, 5 Mar 2006, Junio C Hamano wrote:
> - max_digits = 1 + log(num_blame_lines+1)/log(10);
> + for (max_digits = 1, i = 10; i <= num_blame_lines; max_digits++)
> + i *= 10;
According to my late-night maths skills, these two methods do not do the
same thing: if num_blame_lines == 9, the log method assigns 2 to
max_digits, but the for loop stops at max_digits == 1. A trivial fix would
be to test for i <= num_blame_lines + 1.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-blame: Use the same tests for git-blame as for git-annotate
From: Junio C Hamano @ 2006-03-06 0:19 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <440B751F.5000801@michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> Along these lines, if anyone can pin down the complicated cases that
> annotate and blame get differently, adding them as a test would be
> *exceedingly* appreciated, even if it makes annotate (or blame) fail for
> a bit, it gives us something to work against.
In the t/trash repository, "git-annotate file master" and
"git-annotate file master^" behaves funkily.
OTOH "git-blame file master" assigns everything to that commit
while only the last two lines are attributable to it. Needs a
bit more work on both sides ;-).
^ permalink raw reply
* Re: [PATCH] git-blame: Use the same tests for git-blame as for git-annotate
From: Martin Langhoff @ 2006-03-06 0:29 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <440B751F.5000801@michonline.com>
On 3/6/06, Ryan Anderson <ryan@michonline.com> wrote:
> Along these lines, if anyone can pin down the complicated cases that
> annotate and blame get differently, adding them as a test would be
> *exceedingly* appreciated, even if it makes annotate (or blame) fail for
> a bit, it gives us something to work against.
It would be great if they both worked properly with paths that existed
in the past. Right now, I can't git-annotate or git-blame a file I
know was there in a past revision. I think I had taught Johannes'
annotate to deal with this, or at least intended to. As things stand,
git-annotate/git-blame need a checkout, which is really silly.
Tools like gitweb and cvsserver should be able to do:
GIT_DIR=/somebarerepo/git.git git-(annotate|blame) -h headname Makefile
and not worry about creating a temporary index *and* checking out
Makefile so that things work. That's what cvsserver does now, anyway.
Ugly :-(
cheers,
m
^ permalink raw reply
* Re: [PATCH] Tweak asciidoc output to work with broken docbook-xsl
From: Junio C Hamano @ 2006-03-06 0:53 UTC (permalink / raw)
To: Francis Daly; +Cc: git
In-Reply-To: <20060305231336.GA21797@craic.sysops.org>
Francis Daly <francis@daoine.org> writes:
> docbook-xsl v1.68 incorrectly converts "<screen>" from docbook to
> manpage by not rendering it verbatim. v1.69 handles it correctly, but
> not many current popular distributions ship with it.
>
> asciidoc by default converts "listingblock" to "<screen>". This change
> causes asciidoc in git to convert "listingblock" to "<literallayout>", which
> both old and new docbook-xsl handle correctly.
Have you tested html generation side? With 1.68 I seem to be
getting an disaster.
How about this instead?
---
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index fa0877d..7ce7151 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -18,6 +18,16 @@ ifdef::backend-docbook[]
{0#</citerefentry>}
endif::backend-docbook[]
+ifdef::backend-docbook[]
+# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this.
+[listingblock]
+<example><title>{title}</title>
+<literallayout>
+|
+</literallayout>
+{title#}</example>
+endif::backend-docbook[]
+
ifdef::backend-xhtml11[]
[gitlink-inlinemacro]
<a href="{target}.html">{target}{0?({0})}</a>
^ permalink raw reply related
* git clone downloads objects that are in GIT_OBJECT_DIRECTORY
From: Benjamin LaHaise @ 2006-03-06 1:08 UTC (permalink / raw)
To: git
Hi folks,
Doing a fresh git clone git://some.git.url/ foo seems to download the
entire remote repository even if all the objects are already stored in
GIT_OBJECT_DIRECTORY=/home/bcrl/.git/object . Is this a known bug?
At 100MB for a kernel, this takes a *long* time.
-ben (who needed to free up disk space)
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Re: [PATCH] Tweak asciidoc output to work with broken docbook-xsl
From: Francis Daly @ 2006-03-06 1:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr75gcs20.fsf@assigned-by-dhcp.cox.net>
On Sun, Mar 05, 2006 at 04:53:11PM -0800, Junio C Hamano wrote:
> Francis Daly <francis@daoine.org> writes:
> > asciidoc by default converts "listingblock" to "<screen>". This change
> > causes asciidoc in git to convert "listingblock" to "<literallayout>", which
> > both old and new docbook-xsl handle correctly.
>
> Have you tested html generation side? With 1.68 I seem to be
> getting an disaster.
Oh how stupid of me.
Yes, of course you're right. The backend matters.
Clearly, I don't read the html pages; and no-one (with old stylesheets)
reads the man pages ;-)
Thanks,
f
--
Francis Daly francis@daoine.org
^ permalink raw reply
* git clone does not work with GIT_OBJECT_DIRECTORY set
From: Benjamin LaHaise @ 2006-03-06 1:21 UTC (permalink / raw)
To: git
And another bug (linux-2.6.git was created with a clone of git://.../
while GIT_OBJECT_DIRECTORY was set):
$ git clone linux-2.6.git bootcache.git
fatal: '/home/bcrl/linux-2.6.git/.git': unable to chdir or not a git archive
fatal: unexpected EOF
clone-pack from '/home/bcrl/linux-2.6.git/.git' failed.
$
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ permalink raw reply
* Looking for SCM that lets me publish part of a repository
From: Matt McCutchen @ 2006-03-06 1:31 UTC (permalink / raw)
To: git
Dear GIT people,
For the last week or so, I have been looking for a SCM system to hold
many of my projects, some of which are available to the public and
others of which are not. It would be nice if I could use a single large
private repository on my computer with each project in a separate
folder. Then I would like to pull some of the projects (but not all)
into a world-readable repository on my Web site. I have looked at
several SCMs and have not found a way to make any of them do this, but I
like GIT best on other grounds. Is there a way I can coerce GIT to
clone and pull one folder out of a repository but ignore the rest?
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
^ permalink raw reply
* Re: git clone does not work with GIT_OBJECT_DIRECTORY set
From: Junio C Hamano @ 2006-03-06 1:33 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: git
In-Reply-To: <20060306012115.GG20768@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> writes:
> And another bug (linux-2.6.git was created with a clone of git://.../
> while GIT_OBJECT_DIRECTORY was set):
>
> $ git clone linux-2.6.git bootcache.git
> fatal: '/home/bcrl/linux-2.6.git/.git': unable to chdir or not a git archive
> fatal: unexpected EOF
> clone-pack from '/home/bcrl/linux-2.6.git/.git' failed.
> $
Please try it without GIT_OBJECT_DIRECTORY and see it works
correctly (I think it should). If that is the case, maybe
git-clone should explicitly unset GIT_OBJECT_DIRECTORY.
^ permalink raw reply
* Re: git clone downloads objects that are in GIT_OBJECT_DIRECTORY
From: Shawn Pearce @ 2006-03-06 1:42 UTC (permalink / raw)
To: git
In-Reply-To: <20060306010825.GF20768@kvack.org>
Benjamin LaHaise <bcrl@kvack.org> wrote:
> Hi folks,
>
> Doing a fresh git clone git://some.git.url/ foo seems to download the
> entire remote repository even if all the objects are already stored in
> GIT_OBJECT_DIRECTORY=/home/bcrl/.git/object . Is this a known bug?
> At 100MB for a kernel, this takes a *long* time.
I believe it is a known missing feature. :-) git-clone doesn't
prep HEAD to have some sort of starting point so the pull it uses
to download everything literally downloads everything as nothing
is in common.
One could work around it by running git-init-db to create the new
clone locally, git-update-ref HEAD to some commit which you have in
common with the remote, create a origin file, then perform a git-pull.
This would only download the objects between the commit you put into
HEAD and the current master of the remote... But that is actually
some work.
I think Cogito's clone is capable of restarting a failed clone; I
wonder if that logic would benefit you here?
Is using a common GIT_OBJECT_DIRECTORY across many clones actually
pretty common? Maybe its time that git-clone gets some more smarts
with regards to what it yanks from the origin.
--
Shawn.
^ permalink raw reply
* Re: git clone does not work with GIT_OBJECT_DIRECTORY set
From: Benjamin LaHaise @ 2006-03-06 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzg4cq6y.fsf@assigned-by-dhcp.cox.net>
On Sun, Mar 05, 2006 at 05:33:25PM -0800, Junio C Hamano wrote:
> Please try it without GIT_OBJECT_DIRECTORY and see it works
> correctly (I think it should). If that is the case, maybe
> git-clone should explicitly unset GIT_OBJECT_DIRECTORY.
Nope. There is no .git/objects directory, so how would it be able to
find the objects?
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@kvack.org>.
^ 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