* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: A Large Angry SCM @ 2006-03-06 5:31 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Martin Langhoff, Fredrik Kuivinen, git, junkio
In-Reply-To: <20060306024353.GA23001@mythryan2.michonline.com>
Ryan Anderson wrote:
...
>
> For annotate, the syntax I was using was:
> git annotate Makefile headname
>
> I'm not married to it, so please, send a patch to change it if you want
> (Please fix up the test case I'm sending in this patch, as well.)
>
Wouldn't
git annotate <headname> <filename(s?)>
be more consistent with other git commands?
^ permalink raw reply
* [PATCH] Add git-annotate(1) and git-blame(1)
From: Jonas Fonseca @ 2006-03-06 5:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-annotate.txt | 44 ++++++++++++++++++++++++++++++++++++++++
Documentation/git-blame.txt | 31 ++++++++++++++++++++++++++++
2 files changed, 75 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-annotate.txt
create mode 100644 Documentation/git-blame.txt
c280414507b072689afd3061a2d43527ebab292e
diff --git a/Documentation/git-annotate.txt b/Documentation/git-annotate.txt
new file mode 100644
index 0000000..1cfc3e3
--- /dev/null
+++ b/Documentation/git-annotate.txt
@@ -0,0 +1,44 @@
+git-annotate(1)
+===============
+
+NAME
+----
+git-annotate - annotate file lines with commit info
+
+SYNOPSIS
+--------
+git-annotate [options] file [revision]
+
+DESCRIPTION
+-----------
+Annotates each line in the given file with information from the commit
+which introduced the line. Optionally annotate from a given revision.
+
+OPTIONS
+-------
+-l, --long::
+ Show long rev (Defaults off).
+
+-t, --time::
+ Show raw timestamp (Defaults off).
+
+-r, --rename::
+ Follow renames (Defaults on).
+
+-S, --rev-file <revs-file>::
+ Use revs from revs-file instead of calling git-rev-list.
+
+-h, --help::
+ Show help message.
+
+SEE ALSO
+--------
+gitlink:git-blame[1]
+
+AUTHOR
+------
+Written by Ryan Anderson <ryan@michonline.com>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt
new file mode 100644
index 0000000..bdf28d9
--- /dev/null
+++ b/Documentation/git-blame.txt
@@ -0,0 +1,31 @@
+git-blame(1)
+============
+
+NAME
+----
+git-blame - blame file lines on commits
+
+SYNOPSIS
+--------
+git-blame revision file
+
+DESCRIPTION
+-----------
+Annotates each line in the given file with information from the commit
+which introduced the line. Start annotation from the given revision.
+
+OPTIONS
+-------
+No options.
+
+SEE ALSO
+--------
+gitlink:git-annotate[1]
+
+AUTHOR
+------
+Written by Fredrik Kuivinen <freku045@student.liu.se>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
--
1.2.4.g9201
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] repo-config: give value_ a sane default so regexec won't segfault
From: Jonas Fonseca @ 2006-03-06 5:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
repo-config.c | 5 ++++-
t/t1300-repo-config.sh | 8 ++++++++
2 files changed, 12 insertions(+), 1 deletions(-)
7fcdb6b9c8c75a0c84076b4a0ebc46b4c7383906
diff --git a/repo-config.c b/repo-config.c
index 9cf6519..c5ebb76 100644
--- a/repo-config.c
+++ b/repo-config.c
@@ -14,6 +14,9 @@ static enum { T_RAW, T_INT, T_BOOL } typ
static int show_config(const char* key_, const char* value_)
{
+ if (value_ == NULL)
+ value_ = "";
+
if (!strcmp(key_, key) &&
(regexp == NULL ||
(do_not_match ^
@@ -35,7 +38,7 @@ static int show_config(const char* key_,
sprintf(value, "%s", git_config_bool(key_, value_)
? "true" : "false");
} else {
- value = strdup(value_ ? value_ : "");
+ value = strdup(value_);
}
seen++;
}
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 207dd3d..ab4dd5c 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -247,5 +247,13 @@ EOF
test_expect_success 'hierarchical section value' 'cmp .git/config expect'
+cat > .git/config << EOF
+[novalue]
+ variable
+EOF
+
+test_expect_success 'get variable with no value' \
+ 'git-repo-config --get novalue.variable ^$'
+
test_done
--
1.2.4.g9201
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] annotate: Support annotation of files on other revisions.
From: Martin Langhoff @ 2006-03-06 4:18 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <20060306024353.GA23001@mythryan2.michonline.com>
On 3/6/06, Ryan Anderson <ryan@michonline.com> wrote:
> annotate was *trying* to handle that cleanly, but failed due to a silly
Great stuff, thanks! I'll let it hit master and then I'll drop the
messy part of req_annotate() in cvsserver.
> For annotate, the syntax I was using was:
> git annotate Makefile headname
>
> I'm not married to it, so please, send a patch to change it if you want
> (Please fix up the test case I'm sending in this patch, as well.)
That's _perfect_. I was just making the syntax up.
cheers,
martin
^ permalink raw reply
* Re: git clone downloads objects that are in GIT_OBJECT_DIRECTORY
From: sean @ 2006-03-06 3:31 UTC (permalink / raw)
To: Shawn Pearce; +Cc: junkio, git
In-Reply-To: <20060306025702.GH25790@spearce.org>
On Sun, 5 Mar 2006 21:57:02 -0500
Shawn Pearce <spearce@spearce.org> wrote:
> It might be nicer if the user could place a list of locally (here
> locally being possibly remote but closer network-wise) available
> repositories which should be considered as sources for faster
> cloning. When cloning a remote repository git-clone would try to
> examine each of the designated repositories to see if any of them
> have commits in common with the remote; if so clone off that and
> then pull from the remote, but designating the remote as `origin'.
It is already easy to start from a similar repo (eg. locally cloned)
if you wish to conserve bandwidth.
However, it might be nice to have a command that allows you to
change origin information for a repo without needing to know git
internals; maybe something like:
$ git set-origin <URL>
Or maybe better:
$ git set-remote --pull master:origin origin <URL>
Sean
^ permalink raw reply
* Re: git clone downloads objects that are in GIT_OBJECT_DIRECTORY
From: Shawn Pearce @ 2006-03-06 2:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylwcncn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > 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.
>
> You would first 'clone -l -s' from your local repository and
> then clone into that from whatever remote, perhaps.
Yea but that's about as much fun as creating a bare repository
by hand. (Which I've been doing up until this thread prompted me
to read git-clone.sh and learn the existance of --bare.)
It might be nicer if the user could place a list of locally (here
locally being possibly remote but closer network-wise) available
repositories which should be considered as sources for faster
cloning. When cloning a remote repository git-clone would try to
examine each of the designated repositories to see if any of them
have commits in common with the remote; if so clone off that and
then pull from the remote, but designating the remote as `origin'.
This could be ugly if you have a large number of locally available
candidates or if the candidates are many (e.g. 1000s) commits
behind the remote being cloned. But it would save the user from
pulling down 100+MB of objects they already have while making it
very convient to establish a new repository+working directory based
on someone else's publically available repository.
Or we could just tell the user to create their own clone script,
e.g. kernel-clone:
#!/bin/sh
git-clone -l -n -s ~/kernel-base "$2" &&
cd "$2" &&
echo "URL: $1" >.git/remotes/origin &&
echo "Pull: master:origin" >>.git/remotes/origin &&
git-pull
But it would be better if it was more integrated, and somehow
slightly more automatic...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-blame: Use the same tests for git-blame as for git-annotate
From: Ryan Anderson @ 2006-03-06 2:56 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: 1388 bytes --]
Fredrik Kuivinen wrote:
>Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
>
>
>---
>
> t/annotate-tests.sh | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++
> t/t8001-annotate.sh | 85 +-------------------------------------------------
> t/t8002-blame.sh | 9 +++++
> 3 files changed, 97 insertions(+), 83 deletions(-)
> create mode 100644 t/annotate-tests.sh
> create mode 100755 t/t8002-blame.sh
>
>06b0e500a5202899dcfd037cf78ee4a982da46b4
>diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh
>new file mode 100644
>index 0000000..54a4dfb
>--- /dev/null
>+++ b/t/annotate-tests.sh
>@@ -0,0 +1,86 @@
>+# This file isn't used as a test script directly, instead it is
>+# sourced from t8001-annotate.sh and t8001-blame.sh.
>+
>+test_expect_success \
>+ 'prepare reference tree' \
>+ 'echo "1A quick brown fox jumps over the" >file &&
>+ echo "lazy dog" >>file &&
>+ git add file
>+ GIT_AUTHOR_NAME="A" git commit -a -m "Initial."'
>+
>+test_expect_success \
>+ 'check all lines blamed on A' \
>+ '[ $(git annotate file | awk "{print \$3}" | grep -c "A") == 2 ]'
>
>
This should be $PROG as well, I suspect.
Also, we need to agree on a syntax for working on non-HEAD revisions.
"git annotate $file $commitish" is what I had been using, but it's
really not something I feel strongly about.
--
Ryan Anderson
sometimes Pug Majere
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply
* [PATCH] annotate: Support annotation of files on other revisions.
From: Ryan Anderson @ 2006-03-06 2:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <46a038f90603051629ke34a0a6u89dad995bbd777b0@mail.gmail.com>
This is a bug fix, and cleans up one or two other things spotted during the
course of tracking down the main bug here.
Also, the test-suite is updated to reflect this case.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
---
git-annotate.perl | 7 +++++--
t/t8001-annotate.sh | 6 ++++++
2 files changed, 11 insertions(+), 2 deletions(-)
On Mon, Mar 06, 2006 at 01:29:32PM +1300, Martin Langhoff wrote:
> 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.
annotate was *trying* to handle that cleanly, but failed due to a silly
bug. This is the same bug that Junio pointed out:
cd t
./t8001-annotate.sh
cd trash
../../git-annotate file master
This is fixed by the patch at the end of this email.
> 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 :-(
For annotate, the syntax I was using was:
git annotate Makefile headname
I'm not married to it, so please, send a patch to change it if you want
(Please fix up the test case I'm sending in this patch, as well.)
cdd80fd28d300dd2400bf75ff64ae2bf1a8b92aa
diff --git a/git-annotate.perl b/git-annotate.perl
index d93ee19..5953ac6 100755
--- a/git-annotate.perl
+++ b/git-annotate.perl
@@ -10,6 +10,7 @@ use warnings;
use strict;
use Getopt::Long;
use POSIX qw(strftime gmtime);
+use Data::Dumper;
sub usage() {
print STDERR 'Usage: ${\basename $0} [-s] [-S revs-file] file [ revision ]
@@ -99,7 +100,7 @@ while (my $bound = pop @stack) {
}
}
push @revqueue, $head;
-init_claim( defined $starting_rev ? $starting_rev : 'dirty');
+init_claim( defined $starting_rev ? $head : 'dirty');
unless (defined $starting_rev) {
my $diff = open_pipe("git","diff","-R", "HEAD", "--",$filename)
or die "Failed to call git diff to check for dirty state: $!";
@@ -345,6 +346,7 @@ sub git_cat_file {
return () unless defined $rev && defined $filename;
my $blob = git_ls_tree($rev, $filename);
+ die "Failed to find a blob for $filename in rev $rev\n" if !defined $blob;
my $catfile = open_pipe("git","cat-file", "blob", $blob)
or die "Failed to git-cat-file blob $blob (rev $rev, file $filename): " . $!;
@@ -367,12 +369,13 @@ sub git_ls_tree {
my ($mode, $type, $blob, $tfilename);
while(<$lstree>) {
+ chomp;
($mode, $type, $blob, $tfilename) = split(/\s+/, $_, 4);
last if ($tfilename eq $filename);
}
close($lstree);
- return $blob if $filename eq $filename;
+ return $blob if ($tfilename eq $filename);
die "git-ls-tree failed to find blob for $filename";
}
diff --git a/t/t8001-annotate.sh b/t/t8001-annotate.sh
index 172908a..761d0bc 100755
--- a/t/t8001-annotate.sh
+++ b/t/t8001-annotate.sh
@@ -87,4 +87,10 @@ test_expect_success \
'One line blamed on B2' \
'[ $(git annotate file | awk "{print \$3}" | grep -c "^B2$") == 1 ]'
+test_expect_success \
+ 'Annotating an old revision works' \
+ '[ $(git annotate file master | awk "{print \$3}" | grep -c "^A$") == 2 ] && \
+ [ $(git annotate file master | awk "{print \$3}" | grep -c "^B$") == 2 ]'
+
+
test_done
--
1.2.4.g9201-dirty
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply related
* Re: git clone downloads objects that are in GIT_OBJECT_DIRECTORY
From: Junio C Hamano @ 2006-03-06 2:34 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060306014253.GD25790@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> 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.
You would first 'clone -l -s' from your local repository and
then clone into that from whatever remote, perhaps.
^ permalink raw reply
* Re: Looking for SCM that lets me publish part of a repository
From: Shawn Pearce @ 2006-03-06 1:48 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1141608679.16980.12.camel@mattlaptop>
Matt McCutchen <hashproduct@verizon.net> wrote:
> 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?
No. And actually this is probably not the best way to use GIT.
If you want to segment your work into ``public'' and ``non-public''
then you should at least segment your work into two repositories:
``public'' and ``non-public''. But you really should segment your
repository to a project-by-project basis. That is each project
should have its own repository.
That said if there are many files which will have identical content
across many projects you may be able to save disk space by placing
all objects into a single object directory; but that's entirely
independent of project organization.
Unlike CVS, Subversions, etc. GIT repositories are dirt-cheap to
create. Don't think twice about creating a different repository
for a new project. I think I'm up on about 50 repositories at
this point; however each one is typically less than a megabyte in
total size.
--
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
* 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: 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
* 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
* 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
* 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 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: 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
* 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] 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] 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: 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
* [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: 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] 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
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