* Re: git-diff not showing changes (corrupt repo?)
From: Linus Torvalds @ 2007-10-03 3:44 UTC (permalink / raw)
To: Dan Zwell; +Cc: Junio C Hamano, git, Martin Waitz, Jeff King
In-Reply-To: <470309D5.702@gmail.com>
On Tue, 2 Oct 2007, Dan Zwell wrote:
>
> I bisected twice to be sure, and have CC'd Martin Waitz on this (the issue is
> that some of my changes in a local repo are not being displayed by git-diff,
> either before or after they are committed, but git-status, git-whatchanged,
> and git-diff-tree all see that changes have been committed, and git-diff-files
> does see uncommitted changes).
>
> e88ee2915493213ea0d0be64c542c090fefd4b33 is first bad commit
You most likely have a very buggy "less".
Try this:
echo hello | less -FRSX
on the command line. Do you see the "hello"?
(The above is assuming you haven't set GIT_PAGER, PAGER or the LESS
variables manually to something else)
Linus
^ permalink raw reply
* Re: git-diff not showing changes (corrupt repo?)
From: Jeff King @ 2007-10-03 3:23 UTC (permalink / raw)
To: Dan Zwell; +Cc: Junio C Hamano, git, Martin Waitz
In-Reply-To: <470309D5.702@gmail.com>
On Tue, Oct 02, 2007 at 10:17:41PM -0500, Dan Zwell wrote:
> e88ee2915493213ea0d0be64c542c090fefd4b33 is first bad commit
> commit e88ee2915493213ea0d0be64c542c090fefd4b33
> Author: Martin Waitz <tali@admingilde.org>
> Date: Tue Oct 10 21:16:25 2006 +0200
>
> paginate git-diff by default
The only thing this patch does is run the pager, so presumably git-diff
_is_ generating output, but calling the pager is broken for some reason.
What is the value of $GIT_PAGER and $PAGER on the broken and working
machines? Can you confirm that the pager works on both machines?
> I discovered this problem on my 64 bit machine, but the problem does not
> occur on my 32 bit machine. That is not the only difference between the two
> computers, but it seems the most obvious culprit. The 64 bit machine may
> have different libraries than the other, as they are running different
> distros.
I couldn't reproduce on my 32-bit or 64-bit machine (the former running
Debian unstable, the latter Debian stable). But given the patch you
bisected to, I think it is more likely that your pager is broken on the
64-bit machine.
-Peff
^ permalink raw reply
* Re: git-diff not showing changes (corrupt repo?)
From: Dan Zwell @ 2007-10-03 3:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Waitz, Jeff King
In-Reply-To: <7vbqbhl44h.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Dan Zwell <dzwell@gmail.com> writes:
>
>> ... It is the same after I commit the new changes--at that point,
>> "git-diff-tree HEAD^ HEAD -p" spits out a nice patch, but "git-diff
>> HEAD^ HEAD" gives nothing.
>
> This part is most interesting. They are both about comparing
> two commits and do not interact with anything in the work tree
> nor your index.
>
> ... Can you bisect it?
>
I bisected twice to be sure, and have CC'd Martin Waitz on this (the
issue is that some of my changes in a local repo are not being displayed
by git-diff, either before or after they are committed, but git-status,
git-whatchanged, and git-diff-tree all see that changes have been
committed, and git-diff-files does see uncommitted changes).
e88ee2915493213ea0d0be64c542c090fefd4b33 is first bad commit
commit e88ee2915493213ea0d0be64c542c090fefd4b33
Author: Martin Waitz <tali@admingilde.org>
Date: Tue Oct 10 21:16:25 2006 +0200
paginate git-diff by default
I discovered this problem on my 64 bit machine, but the problem does not
occur on my 32 bit machine. That is not the only difference between the
two computers, but it seems the most obvious culprit. The 64 bit machine
may have different libraries than the other, as they are running
different distros.
I noticed that this is a rather old (and very small) patch, and I don't
quite understand how it could cause this problem. I could not revert the
patch to fix the problem. I placed a stripped down version of the
repository here: http://zwell.net/git-error.tar.gz. The problem is very
easy to observe on my machine, though it looks like some machines do not
exhibit it. What else can I do to help?
Dan
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Jeff King @ 2007-10-03 2:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vr6kdhwsg.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 02, 2007 at 05:22:23PM -0700, Junio C Hamano wrote:
> > strbuf_init(&url);
> > strbuf_addf(&url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
>
> Ugh, this typically calls snprintf() twice doesn't it?
Yes, it probably does. However, I think it is considerably easier to
read and more maintainable. Are you "ugh"ing because of the performance
impact (which should be negligible unless this is in a tight loop) or
because of the portability problems associated with va_copy?
-Peff
^ permalink raw reply
* [PATCH] Restore default verbosity for http fetches.
From: Daniel Barkalow @ 2007-10-03 2:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This adds a verbosity level below 0 for suppressing default messages
with --quiet, and makes the default for http be verbose instead of
quiet. This matches the behavior of the shell script version of git-fetch.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
builtin-fetch.c | 2 +-
transport.c | 10 +++++-----
transport.h | 2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ac68ff5..cf7498b 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -533,7 +533,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
if (verbose >= 2)
transport->verbose = 1;
if (quiet)
- transport->verbose = 0;
+ transport->verbose = -1;
if (upload_pack)
set_option(TRANS_OPT_UPLOADPACK, upload_pack);
if (keep)
diff --git a/transport.c b/transport.c
index 7266fd3..6fe6ec8 100644
--- a/transport.c
+++ b/transport.c
@@ -161,7 +161,7 @@ static struct ref *get_refs_via_rsync(const struct transport *transport)
rsync.argv = args;
rsync.stdout_to_stderr = 1;
args[0] = "rsync";
- args[1] = transport->verbose ? "-rv" : "-r";
+ args[1] = (transport->verbose > 0) ? "-rv" : "-r";
args[2] = buf.buf;
args[3] = temp_dir.buf;
args[4] = NULL;
@@ -214,7 +214,7 @@ static int fetch_objs_via_rsync(struct transport *transport,
rsync.argv = args;
rsync.stdout_to_stderr = 1;
args[0] = "rsync";
- args[1] = transport->verbose ? "-rv" : "-r";
+ args[1] = (transport->verbose > 0) ? "-rv" : "-r";
args[2] = "--ignore-existing";
args[3] = "--exclude";
args[4] = "info";
@@ -290,7 +290,7 @@ static int rsync_transport_push(struct transport *transport,
rsync.argv = args;
rsync.stdout_to_stderr = 1;
args[0] = "rsync";
- args[1] = transport->verbose ? "-av" : "-a";
+ args[1] = (transport->verbose > 0) ? "-av" : "-a";
args[2] = "--ignore-existing";
args[3] = "--exclude";
args[4] = "info";
@@ -344,7 +344,7 @@ static int fetch_objs_via_walker(struct transport *transport,
walker->get_all = 1;
walker->get_tree = 1;
walker->get_history = 1;
- walker->get_verbosely = transport->verbose;
+ walker->get_verbosely = transport->verbose >= 0;
walker->get_recover = 0;
for (i = 0; i < nr_objs; i++)
@@ -637,7 +637,7 @@ static int fetch_refs_via_pack(struct transport *transport,
args.keep_pack = data->keep;
args.lock_pack = 1;
args.use_thin_pack = data->thin;
- args.verbose = transport->verbose;
+ args.verbose = transport->verbose > 0;
args.depth = data->depth;
for (i = 0; i < nr_heads; i++)
diff --git a/transport.h b/transport.h
index 6e318e4..4bb51d7 100644
--- a/transport.h
+++ b/transport.h
@@ -24,7 +24,7 @@ struct transport {
int (*disconnect)(struct transport *connection);
char *pack_lockfile;
- unsigned verbose : 1;
+ signed verbose : 2;
};
#define TRANSPORT_PUSH_ALL 1
--
1.5.3.2.1107.ge9eab8-dirty
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Linus Torvalds @ 2007-10-03 2:28 UTC (permalink / raw)
To: David Kastrup, Jeff King; +Cc: Git Mailing List
In-Reply-To: <86ve9p32cp.fsf@lola.quinscape.zz>
[ This is the discussed stupid approach - just sort the dang hash array,
so that we can use a linear scan over the src/dst ]
On Tue, 2 Oct 2007, David Kastrup wrote:
>
> This does not actually require an actual merge _sort_ AFAICS: do the
> "sort file.hashed" step using qsort. The comparison step does not
> actually need to produce merged output, but merely advances through
> two hash arrays and generates statistics.
>
> This should already beat the pants off the current implementation,
> even when the hash array is sparse, simply because our inner loop then
> has perfect hash coherence.
Sadly, that's not the case. It *does* seem to beat the current
implementation, but it's not "beat the pants off". It looks like an
improvement of about 15%, which is nothing to sneeze at, but it's not an
order-of-magnitude improvement either.
Here's a test-patch. I don't guarantee anything, except that when I did
the timings I also did a "wc" on the result, and they matched..
Before:
[torvalds@woody linux]$ time git diff -l0 --stat -C v2.6.22.. | wc
7104 28574 438020
real 0m10.526s
user 0m10.401s
sys 0m0.136s
After:
[torvalds@woody linux]$ time ~/git/git diff -l0 --stat -C v2.6.22.. | wc
7104 28574 438020
real 0m8.876s
user 0m8.761s
sys 0m0.128s
but the diff is fairly simple, so if somebody will go over it and say
whether it's likely to be *correct* too, that 15% may well be worth it.
[ Side note, without rename detection, that diff takes just under three
seconds for me, so in that sense the improvement to the rename detection
itself is larger than the overall 15% - it brings the cost of just
rename detection from 7.5s to 5.9s, which would be on the order of just
over a 20% performance improvement. ]
Hmm. The patch depends on half-way subtle issues like the fact that the
hashtables are guaranteed to not be full => we're guaranteed to have zero
counts at the end => we don't need to do any steenking iterator count in
the loop. A few comments might in order.
Linus
---
diffcore-delta.c | 54 ++++++++++++++++++++++++++++++------------------------
1 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/diffcore-delta.c b/diffcore-delta.c
index d9729e5..6d65697 100644
--- a/diffcore-delta.c
+++ b/diffcore-delta.c
@@ -46,22 +46,6 @@ struct spanhash_top {
struct spanhash data[FLEX_ARRAY];
};
-static struct spanhash *spanhash_find(struct spanhash_top *top,
- unsigned int hashval)
-{
- int sz = 1 << top->alloc_log2;
- int bucket = hashval & (sz - 1);
- while (1) {
- struct spanhash *h = &(top->data[bucket++]);
- if (!h->cnt)
- return NULL;
- if (h->hashval == hashval)
- return h;
- if (sz <= bucket)
- bucket = 0;
- }
-}
-
static struct spanhash_top *spanhash_rehash(struct spanhash_top *orig)
{
struct spanhash_top *new;
@@ -122,6 +106,20 @@ static struct spanhash_top *add_spanhash(struct spanhash_top *top,
}
}
+static int spanhash_cmp(const void *_a, const void *_b)
+{
+ const struct spanhash *a = _a;
+ const struct spanhash *b = _b;
+
+ /* A count of zero compares at the end.. */
+ if (!a->cnt)
+ return !b->cnt ? 0 : 1;
+ if (!b->cnt)
+ return -1;
+ return a->hashval < b->hashval ? -1 :
+ a->hashval > b->hashval ? 1 : 0;
+}
+
static struct spanhash_top *hash_chars(struct diff_filespec *one)
{
int i, n;
@@ -158,6 +156,10 @@ static struct spanhash_top *hash_chars(struct diff_filespec *one)
n = 0;
accum1 = accum2 = 0;
}
+ qsort(hash->data,
+ 1ul << hash->alloc_log2,
+ sizeof(hash->data[0]),
+ spanhash_cmp);
return hash;
}
@@ -169,7 +171,7 @@ int diffcore_count_changes(struct diff_filespec *src,
unsigned long *src_copied,
unsigned long *literal_added)
{
- int i, ssz;
+ struct spanhash *s, *d;
struct spanhash_top *src_count, *dst_count;
unsigned long sc, la;
@@ -190,22 +192,26 @@ int diffcore_count_changes(struct diff_filespec *src,
}
sc = la = 0;
- ssz = 1 << src_count->alloc_log2;
- for (i = 0; i < ssz; i++) {
- struct spanhash *s = &(src_count->data[i]);
- struct spanhash *d;
+ s = src_count->data;
+ d = dst_count->data;
+ for (;;) {
unsigned dst_cnt, src_cnt;
if (!s->cnt)
- continue;
+ break;
+ while (d->cnt) {
+ if (d->hashval >= s->hashval)
+ break;
+ d++;
+ }
src_cnt = s->cnt;
- d = spanhash_find(dst_count, s->hashval);
- dst_cnt = d ? d->cnt : 0;
+ dst_cnt = d->hashval == s->hashval ? d->cnt : 0;
if (src_cnt < dst_cnt) {
la += dst_cnt - src_cnt;
sc += src_cnt;
}
else
sc += dst_cnt;
+ s++;
}
if (!src_count_p)
^ permalink raw reply related
* Re: WIP: asciidoc replacement
From: Sam Vilain @ 2007-10-03 1:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710030133020.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> I do not want to depend on more than necessary in msysGit, and therefore I
> started to write an asciidoc replacement.
>
> So here it is: a perl script that does a good job on many .txt files in
> Documentation/, although for some it deviates from "make man"'s output,
> and for others it is outright broken. It is meant to be run in
> Documentation/.
>
> My intention is not to fix the script for all cases, but to make patches
> to Documentation/*.txt themselves, so that they are more consistent (and
> incidentally nicer to the script).
>
> Now, I hear you already moan: "But Dscho, you know you suck at Perl!"
>
> Yeah, I know, but maybe instead of bashing on me (pun intended), you may
> want to enlighten me with tips how to make it nicer to read. (Yes, there
> are no comments; yes, I will gladly add them where appropriate; yes, html
> is just a stub.)
>
> So here, without further ado, da script:
It's pretty good, I certainly wouldn't have trouble reading or
maintaining it, but I'll give you suggestions anyway.
nice work, replacing a massive XML/XSL/etc stack with a small Perl
script ;-)
Sam.
>
> -- snip --
> #!/usr/bin/perl
Add -w for warnings, also use strict;
> $conv = new man_page();
> $conv->{manual} = 'Git Manual';
> $conv->{git_version} = 'Git ' . `cat ../GIT-VERSION-FILE`;
> $conv->{git_version} =~ s/GIT_VERSION = //;
> $conv->{git_version} =~ s/-/\\-/;
> $conv->{git_version} =~ s/\n//;
> $conv->{date} = `date +%m/%d/%Y`;
> $conv->{date} =~ s/\n//;
>
> $par = '';
> handle_file($ARGV[0]);
> $conv->finish();
>
> sub handle_text {
this function acts on globals; make them explicit arguments to the function.
> if ($par =~ /^\. /s) {
> my @lines = split(/^\. /m, $par);
> shift @lines;
> $conv->enumeration(\@lines);
> } elsif ($par =~ /^\* /s) {
uncuddle your elsif's; also consider making this a "tabular ternary"
with the actions in separate functions.
ie
$result = ( $par =~ /^\. /s ? $conv->do_enum($par) :
$par =~ /^\[verse\]/ ? $conv->do_verse($par) :
... )
However I have a suspicion that your script is doing line-based parsing
instead of recursive descent; I don't know whether that's the right
thing for asciidoc. It's actually fairly easy to convert a grammar to
code blocks using tricks from MJD's _Higher Order Perl_. Is it
necessary for the asciidoc grammar?
> my @lines = split(/^\* /m, $par);
> shift @lines;
> $conv->enumeration(\@lines, 'unnumbered');
> } elsif ($par =~ /^\[verse\]/) {
> $par =~ s/\[verse\] *\n?//;
> $conv->verse($par);
> } elsif ($par =~ /^(\t| +)/s) {
> $par =~ s/^$1//mg;
> $par =~ s/^\+$//mg;
> $conv->indent($par);
> } elsif ($par =~ /^([^\n]*)::\n((\t| +).*)$/s) {
> my ($first, $rest, $indent) = ($1, $2, $3);
> $rest =~ s/^\+$//mg;
> while ($rest =~ /^(.*?\n\n)--+\n(.*?\n)--+\n\n(.*)$/s) {
> my ($pre, $verb, $post) = ($1, $2, $3);
>
> $pre =~ s/^(\t|$indent)//mg;
> if ($first ne '') {
> $conv->begin_item($first, $pre);
> $first = '';
> } else {
> $conv->normal($pre);
> }
>
> $conv->verbatim($verb);
> $rest = $post;
> }
> $rest =~ s/^(\t|$indent)//mg;
> if ($first ne '') {
> $conv->begin_item($first, $rest);
> } else {
> $conv->normal($rest);
> }
> $conv->end_item();
> } elsif ($par =~ /^-+\n(.*\n)-+\n$/s) {
> $conv->verbatim($1);
> } else {
> $conv->normal($par);
> }
> $par = '';
> }
>
> sub handle_file {
> my $in;
> open($in, '<' . $_[0]);
> while (<$in>) {
> if (/^=+$/) {
> if ($par ne '' && length($_) >= length($par)) {
> $conv->header($par);
> $par = '';
> next;
> }
> } elsif (/^-+$/) {
> if ($par ne '' && length($_) >= length($par)) {
> $conv->section($par);
> $par = '';
> next;
> }
> } elsif (/^~+$/) {
> if ($par ne '' && length($_) >= length($par)) {
> $conv->subsection($par);
> $par = '';
> next;
> }
> } elsif (/^\[\[(.*)\]\]$/) {
> handle_text();
> $conv->anchor($1);
> next;
> } elsif (/^$/) {
> if ($par =~ /^-+\n.*[^-]\n$/s) {
> # fallthru; is verbatim, but needs more.
> } elsif ($par =~ /::\n$/s) {
> # is item, but needs more.
> next;
> } else {
> handle_text();
> next;
> }
> } elsif (/^include::(.*)\[\]$/) {
> handle_text();
> handle_file($1);
> next;
> }
>
> # convert "\--" to "--"
> s/\\--/--/g;
> # convert "\*" to "*"
> s/\\\*/*/g;
>
> # handle gitlink:
> s/gitlink:([^\[ ]*)\[(\d+)\]/sprintf "%s",
> $conv->get_link($1, $2)/ge;
> # handle link:
> s/link:([^\[ ]*)\[(.+)\]/sprintf "%s",
> $conv->get_link($1, $2, 'external')/ge;
These REs suffer from LTS (Leaning Toothpick Syndrome). Consider using
s{foo}{bar} and adding the 'x' modifier to space out groups.
>
> $par .= $_;
> }
> close($in);
> handle_text();
> }
>
> package man_page;
>
> sub new {
> my ($class) = @_;
> my $self = {
> sep => '',
> links => [],
> # generator => 'Home grown git txt2man converter'
> generator => 'DocBook XSL Stylesheets v1.71.1 <http://docbook.sf.net/>'
> };
> bless $self, $class;
> return $self;
> }
>
> sub header {
> my ($self, $text) = @_;
> $text =~ s/-/\\-/g;
>
> if ($self->{preamble_shown} == undef) {
> $title = $text;
> $title =~ s/\(\d+\)$//;
> print '.\" Title: ' . $title
> . '.\" Author: ' . "\n"
> . '.\" Generator: ' . $self->{generator} . "\n"
> . '.\" Date: ' . $self->{date} . "\n"
> . '.\" Manual: ' . $self->{manual} . "\n"
> . '.\" Source: ' . $self->{git_version} . "\n"
> . '.\"' . "\n";
> }
I'd consider a HERE-doc, or multi-line qq{ } more readable than this.
>
> $text =~ tr/a-z/A-Z/;
> my $suffix = "\"$self->{date}\" \"$self->{git_version}\""
> . " \"$self->{manual}\"";
Use qq{} when making strings with lots of embedded double quotes and
interpolation.
> $text =~ s/^(.*)\((\d+)\)$/.TH "\1" "\2" $suffix/;
> print $text;
>
> if ($self->{preamble_shown} == undef) {
> print '.\" disable hyphenation' . "\n"
> . '.nh' . "\n"
> . '.\" disable justification (adjust text to left'
> . ' margin only)' . "\n"
> . '.ad l' . "\n";
Using commas rather than "." will safe you a concat when printing to
filehandles, but that's a very small nit to pick :)
> $self->{preamble_shown} = 1;
> }
>
> $self->{last_op} = 'header';
> }
>
> sub section {
> my ($self, $text) = @_;
>
> $text =~ tr/a-z/A-Z/;
> $text =~ s/^(.*)$/.SH "\1"/;
>
> print $text;
>
> $self->{last_op} = 'section';
> }
>
> sub subsection {
> my ($self, $text) = @_;
>
> $text =~ s/^(.*)$/.SS "\1"/;
>
> print $text;
>
> $self->{last_op} = 'subsection';
> }
>
> sub get_link {
> my ($self, $command, $section, $option) = @_;
>
> if ($option eq 'external') {
> my $links = $self->{links};
> push(@$links, $command);
> $command =~ s/\.html$//;
> $command =~ s/-/ /g;
> push(@$links, $command);
> return '\fI' . $command . '\fR\&[1]';
> } else {
> return '\fB' . $command . '\fR(' . $section . ')';
> }
> }
>
> sub common {
> my ($self, $text, $option) = @_;
>
> # escape backslashes, but not in "\n", "\&" or "\fB"
> $text =~ s/\\(?!n|f[A-Z]|&)/\\\\/g;
> # escape "-"
> $text =~ s/-/\\-/g;
> # handle ...
> $text =~ s/(\.\.\.)/\\&\1/g;
> # remove double space after full stop or comma
> $text =~ s/([\.,]) /\1 /g;
>
> if ($option ne 'no-markup') {
> # make 'italic'
> $text =~ s/'([^'\n]*)'/\\fI\1\\fR/g;
> # ignore `
> $text =~ s/`//g;
> # make *bold*
> $text =~ s/\*([^\*\n]*)\*/\\fB\1\\fR/g;
> # handle <<sections>
> $text =~ s/<<([^>]*)>>/the section called \\(lq\1\\(rq/g;
Hmm, that regex would not match for <<foo > bar>>, if you care you'd
need to write something like <<((?:[^>]+|>[^>])*)>>
> }
>
> return $text;
> }
>
> sub normal {
> my ($self, $text) = @_;
>
> if ($text eq "") {
> return;
> }
>
> $text = $self->common($text);
>
> $text =~ s/ *\n(.)/ \1/g;
>
> if ($self->{last_op} eq 'normal') {
> print "\n";
> }
>
> print $text;
>
> $self->{last_op} = 'normal';
> }
>
> sub verse {
> my ($self, $text) = @_;
>
> $text = $self->common($text);
> $text =~ s/^\t/ /mg;
>
> print ".sp\n.RS 4\n.nf\n" . $text . ".fi\n.RE\n";
>
> $self->{last_op} = 'verse';
> }
>
> sub enumeration {
> my ($self, $text, $option) = @_;
>
> my $counter = 0;
> foreach $line (@$text) {
> $counter++;
> print ".TP 4\n"
> . ($option eq 'unnumbered' ? '\(bu' : $counter . '.')
> . "\n"
> . $self->common($line);
> }
>
> $self->{last_op} = 'enumeration';
> }
>
> sub begin_item {
> my ($self, $item, $text) = @_;
>
> $item = $self->common($item);
> $text = $self->common($text);
>
> $text =~ s/([^\n]) *\n([^\n])/\1 \2/g;
"." is the same as [^\n] (without the 's' modifier).
>
> print ".PP\n" . $item . "\n.RS 4\n" . $text;
>
> $self->{last_op} = 'item';
> }
>
> sub end_item {
> my ($self) = @_;
>
> print ".RE\n";
>
> $self->{last_op} = 'end_item';
> }
>
> sub indent {
> my ($self, $text) = @_;
>
> $text = $self->common($text, 'no-markup');
> $text =~ s/^\t/ /mg;
>
> if ($self->{last_op} eq 'normal') {
> print "\n";
> }
>
> print ".sp\n.RS 4\n.nf\n" . $text . ".fi\n.RE\n";
>
> $self->{last_op} = 'indent';
> }
>
> sub verbatim {
> my ($self, $text) = @_;
>
> $text = $self->common($text, 'no-markup');
>
> # convert tabs to spaces
> $text =~ s/^\t/ /mg;
> # remove trailing empty lines
> $text =~ s/\n\n*$/\n/;
>
> if ($self->{last_op} eq 'normal') {
> print "\n";
> }
>
> print ".sp\n.RS 4\n.nf\n.ft C\n" . $text . ".ft\n\n.fi\n.RE\n";
>
> $self->{last_op} = 'verbatim';
> }
>
> sub anchor {
> my ($self, $text) = @_;
>
> $self->{last_op} = 'anchor';
> }
>
> sub finish {
> my ($self) = @_;
> my $links = $self->{links};
>
> if ($#$links >= 0) {
> print '.SH "REFERENCES"' . "\n";
> my $i = 1;
> while ($#$links >= 0) {
just use if (@$links) and while (@$links)
> my $ref = shift(@$links);
> $ref =~ s/-/\\-/g;
> my $label = shift(@$links);
> printf (".IP \"% 2d.\" 4\n%s\n.RS 4\n\\%%%s\n.RE\n",
> $i++, $label, $ref);
> }
> } else {
> print "\n";
> }
> }
>
> package html_page;
>
> sub new {
> my ($class) = @_;
> my $self = {};
> bless $self, $class;
> return $self;
> }
>
> -- snap --
>
> Ciao,
> Dscho
>
> P.S.: I need to catch some Zs, and do some real work, so do not be
> surprised if I do not respond within the next 24 hours.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] the ar tool is called gar on some systems
From: Robert Schiele @ 2007-10-03 1:49 UTC (permalink / raw)
To: git; +Cc: gitster
Some systems that have only installed the GNU toolchain (prefixed with "g")
do not provide "ar" but only "gar". Make configure find this tool as well.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
---
I sent that some weeks ago but it seems it got lost.
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 84fd7f1..ed7cc89 100644
--- a/configure.ac
+++ b/configure.ac
@@ -104,7 +104,7 @@ AC_MSG_NOTICE([CHECKS for programs])
#
AC_PROG_CC([cc gcc])
#AC_PROG_INSTALL # needs install-sh or install.sh in sources
-AC_CHECK_TOOL(AR, ar, :)
+AC_CHECK_TOOLS(AR, [gar ar], :)
AC_CHECK_PROGS(TAR, [gtar tar])
# TCLTK_PATH will be set to some value if we want Tcl/Tk
# or will be empty otherwise.
--
1.5.2.3
^ permalink raw reply related
* Re: [PATCH] diffcore-rename: cache file deltas
From: Linus Torvalds @ 2007-10-03 1:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy7eu4eos.fsf@gitster.siamese.dyndns.org>
On Tue, 25 Sep 2007, Junio C Hamano wrote:
> >
> > - the name diff_free_filespec_data_large is horrible, but this is based
> > on the fact that diff_free_filespec_data actually does too much (it
> > frees the data _and_ some other auxiliary data). And renaming that
> > would entail changing many callsites.
>
> True. But we can rename it to diff_file_filespec_blob() and
> that would perfectly well describe what it does. Will do so
> when applying if it is Ok to you.
Well, that renaming apparently never happened, and it's still called
diff_free_filespec_data_large() now that it's in master.
That said, I think this patch should make it into the maintenance branch
too, renamed or not, since it's such a huge performance issue.
Linus
^ permalink raw reply
* Re: git-svn merge helper
From: Björn Steinbrink @ 2007-10-03 1:02 UTC (permalink / raw)
To: Steven Walter; +Cc: git
In-Reply-To: <20071003004252.GA28495@dervierte>
On 2007.10.02 20:42:52 -0400, Steven Walter wrote:
> On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:
> > > The other option is to have a "build" branch. By example:
> > >
> > > git checkout build
> > > git reset --hard master
> > > git merge mybranch
> > > make
> > >
> > > In that way, I have branch with the latest changes from head and the
> > > changes from mybranch together. The downside to this method is that you
> > > may have to repeated resolve merges. Despite the downsides, I find
> > > these two methods to work quite well.
> >
> > Thanks, but it makes no difference here, it stil results in a fast
> > forward. This is a small test case which exhibits the behaviour and
> > matches my current workflow with git-svn (except for the dcommits):
> >
> > git init
> > echo Hi > file1; git add file1; git commit -m file1
> > git checkout -b branch
> > echo Hi > file2; git add file2; git commit -m file2
> > git checkout master
> > echo Hi > file3; git add file3; git commit -m file3
> > git checkout branch
> > git merge master
> >
> > # Then I'd normally do the following which causes a fast forward
> > #git checkout master
> > #git merge branch
> >
> > # Now I tried this, which also results in a fast-forward:
> > git checkout -b merge
> > git reset --hard master
> > git merge branch
>
> I believe you misunderstood my suggestion. In using a "build" branch,
> you would not merge master into branch, as you did above. Instead, you
> would create a third, unpublished branch to hold the merge.
Almost though so.
> At the same time, I have a slightly better understanding of what it is
> you're trying to do. If you are trying to keep up an SVN-like workflow
> (namely pulling changes from trunk into a branch from time to time),
> then my solution probably isn't suitable for you. However, you might
> consider why you actually /need/ to do that, outside of SVN convention.
Due to the same reason for which the branch needs to be public at all,
there are other people who want to follow it and test it, while there
are external dependencies that currently change quite often. So I need
to get the relevant changes from trunk into my branch anyway, even with
svn conventions put aside (well, unless I force everyone else to merge
over and over again). And as sometimes others commit to that branch, too
(you just have to love that), keeping a separate branch for the final
merge isn't so nice either, as I'd need to constantly cherry-pick those
changes then and probably get even more conflicts along the way.
That said, Google finally liked some of the search terms that I threw at
it and revealed a thread [1] from march, where Linus was torn on whether
or not a --no-fast-forward option should be introduced. That sounds like
it would help here, any chance of getting such a thing?
Thanks,
Björn
[1]
http://lists-archives.org/git/419374-git-merge-and-merge-message.html
^ permalink raw reply
* [PATCH] git-diff: complain about >=8 consecutive spaces in initial indent
From: Junio C Hamano @ 2007-10-03 1:00 UTC (permalink / raw)
To: git; +Cc: J. Bruce Fields
In-Reply-To: <1189982942187-git-send-email-bfields@citi.umich.edu>
This teaches coloring code in "diff" to detect indent of 8 or
more places using SP, which can and should (in some projects
including the kernel and git itself) use HT instead.
---
* This is primarily meant as a "reminder" patch, and not for
inclusion. We earlier saw a patch to "git-apply" to rewrite
them to HT but rejected it, because some projects use "no HT,
all SP" policy (e.g. Python).
We probably should resurrect the earlier "git-apply" patch,
and teach it and this patch to selectively enable/disable
detection of different kinds of whitespace breakages.
diff.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 0ee9ea1..647377b 100644
--- a/diff.c
+++ b/diff.c
@@ -531,8 +531,10 @@ static void emit_line_with_ws(int nparents,
int i;
int tail = len;
int need_highlight_leading_space = 0;
- /* The line is a newly added line. Does it have funny leading
- * whitespaces? In indent, SP should never precede a TAB.
+ /*
+ * The line is a newly added line. Does it have funny leading
+ * whitespaces? In indent, SP should never precede a TAB, and
+ * there shouldn't be more than 8 consecutive spaces.
*/
for (i = col0; i < len; i++) {
if (line[i] == '\t') {
@@ -545,6 +547,11 @@ static void emit_line_with_ws(int nparents,
else
break;
}
+ if (0 <= last_space_in_indent && last_tab_in_indent < 0 &&
+ 8 <= (i - col0)) {
+ last_tab_in_indent = i;
+ need_highlight_leading_space = 1;
+ }
fputs(set, stdout);
fwrite(line, col0, 1, stdout);
fputs(reset, stdout);
^ permalink raw reply related
* Re: metastore
From: Johannes Schindelin @ 2007-10-03 0:52 UTC (permalink / raw)
To: david
Cc: Julian Phillips, David H?rdeman, martin f krafft, git,
Daniel Barkalow, Thomas Harning Jr., Francis Moreau, Nicolas Vilz
In-Reply-To: <Pine.LNX.4.64.0710021743270.25489@asgard.lang.hm>
Hi,
On Tue, 2 Oct 2007, david@lang.hm wrote:
> in the discussion a few weeks ago I was told that there is a way to look
> at the contents of a file that hasn't been checked out yet (somehow it
> exists in a useable form 'in the index') but when I asked for
> information about how to do this I never got a response.
git show :<filename>
(Note the ":")
Hth,
Dscho
^ permalink raw reply
* Re: metastore
From: david @ 2007-10-03 0:52 UTC (permalink / raw)
To: Julian Phillips
Cc: David Härdeman, David Kastrup, martin f krafft, git,
Daniel Barkalow, Johannes Schindelin, Thomas Harning Jr.,
Francis Moreau, Nicolas Vilz
In-Reply-To: <Pine.LNX.4.64.0710030018240.4087@reaper.quantumfyre.co.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4935 bytes --]
On Wed, 3 Oct 2007, Julian Phillips wrote:
> Subject: Re: metastore
>
> On Tue, 2 Oct 2007, David Härdeman wrote:
>
>> On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:
>>> David Härdeman <david@hardeman.nu> writes:
>>>
>>> > On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>>> > > also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016
>>> +0100]:
>>> > > > But I agree, if any changes were made to git, I'd advocate adding
>>> > > > arbitrary attributes to files (much like xattrs) in name=value
>>> > > > pairs, then any extended metadata could be stored in those
>>> > > > attributes and external scripts/tools could use them in some way
>>> > > > that makes sense...and also make sure to only update them when it
>>> > > > makes sense.
>>> > > > > So where would those metdata be stored in your opinion?
>>> > > I'm not sufficiently versed in the internals of git to have an
>>> > informed opinion :)
>>>
>>> I think we have something like a length count for file names in index
>>> and/or tree. We could just put the (sorted) attributes after a NUL
>>> byte in the file name and include them in the count. It would also
>>> make those artificially longer file names work more or less when
>>> sorting them for deltification.
>>
>> Or perhaps the index format could be extended to include a new field for
>> value=name pairs instead of overloading the name field.
>>
>> But as I said, I have no idea how feasible it would be to change git to
>> support another arbitrary length field in the index/tree file.
>>
>>> However, this requires implementing _policies_: it must be possible to
>>> specify per repository exactly what will and what won't get tracked,
>>> or one will get conflicts that are not necessary or appropriate.
>>
>> I think the opposite approach would be better. Let git provide
>> set/get/delete attribute operations and leave it at that. Then external
>> programs can do what they want with that data and add/remove/modify tags as
>> necessary (and also include the smarts to not, e.g. remove the permissions
>> on all files if the git repo is checked out to a FAT fs).
>
> You need more than that. You need to be able to log, blame etc on the
> attributes. One of the big annoyances of Subversion properties is being
> unable to find out when or why a property value was changed.
>
> I still don't see why the attributes need to be stored in git directly -
> particularly if you are going to use an external program to actually apply
> any settings - why not store the attributes as normal file (or files) of some
> sort tracked by git? You could use any number of methods - e.g. use an
> sqlite database stored in the root of your tree, or a .<name>.props file
> alongside each path that you have properties for. You could even write a
> system that uses such a method and was then SCM agnostic, allowing you to
> keep your attribute tracking system if/when something better than git comes
> along - or simply share it with less-fortunate souls stuck in an inferior
> system.
one other big advantage of keeping things in a normal file, it's easier to
get the results accepted into git!
don't forget that the core git maintainers don't really see this as a
worthwhile effort, so the more intrusive the result is the less likely it
is to be accepted. It may end up that storing the attributes inside of git
_is_ the best thing to do, but it's gong to be a whole lot easier to get a
patch to implement this accepted if it's a migration from an existing,
heavily used, implementation then if it's from the 'outside' with people
saying "this is a neat thing, we think people would use it if it only had
this"
and even if an internal implementation does end up being the right thing,
the exact shape of the API is an item that will require a lot of debate
(and probably a few false starts) to get right. let's figure out the
real-world useage patterns first, and then work from there as appropriate.
shifting back onto implementaion details
in the discussion a few weeks ago I was told that there is a way to look
at the contents of a file that hasn't been checked out yet (somehow it
exists in a useable form 'in the index') but when I asked for information
about how to do this I never got a response.
the reason for needing this is that the routines writing the files need to
be able to access this information when they are dong so, but that file
may not be checked out.
for that matter, .gitattributes should have a similar problem (if
.gitattibutes for a directory hasn't been checked out yet how do you know
if you could do the line ending conversions on a file or not?). how is the
problem addressed there? (or is it the case that all the use so far has
really not used the per-directory files and everything is in the master
file, and that doesn't change enough to find these problems?
David Lang
^ permalink raw reply
* Re: git-svn merge helper
From: Steven Walter @ 2007-10-03 0:42 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071002223813.GA3152@atjola.homenet>
On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote:
> > The other option is to have a "build" branch. By example:
> >
> > git checkout build
> > git reset --hard master
> > git merge mybranch
> > make
> >
> > In that way, I have branch with the latest changes from head and the
> > changes from mybranch together. The downside to this method is that you
> > may have to repeated resolve merges. Despite the downsides, I find
> > these two methods to work quite well.
>
> Thanks, but it makes no difference here, it stil results in a fast
> forward. This is a small test case which exhibits the behaviour and
> matches my current workflow with git-svn (except for the dcommits):
>
> git init
> echo Hi > file1; git add file1; git commit -m file1
> git checkout -b branch
> echo Hi > file2; git add file2; git commit -m file2
> git checkout master
> echo Hi > file3; git add file3; git commit -m file3
> git checkout branch
> git merge master
>
> # Then I'd normally do the following which causes a fast forward
> #git checkout master
> #git merge branch
>
> # Now I tried this, which also results in a fast-forward:
> git checkout -b merge
> git reset --hard master
> git merge branch
I believe you misunderstood my suggestion. In using a "build" branch,
you would not merge master into branch, as you did above. Instead, you
would create a third, unpublished branch to hold the merge.
At the same time, I have a slightly better understanding of what it is
you're trying to do. If you are trying to keep up an SVN-like workflow
(namely pulling changes from trunk into a branch from time to time),
then my solution probably isn't suitable for you. However, you might
consider why you actually /need/ to do that, outside of SVN convention.
--
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
-Robert Heinlein
^ permalink raw reply
* WIP: asciidoc replacement
From: Johannes Schindelin @ 2007-10-03 0:42 UTC (permalink / raw)
To: git, msysgit
Hi,
I do not want to depend on more than necessary in msysGit, and therefore I
started to write an asciidoc replacement.
So here it is: a perl script that does a good job on many .txt files in
Documentation/, although for some it deviates from "make man"'s output,
and for others it is outright broken. It is meant to be run in
Documentation/.
My intention is not to fix the script for all cases, but to make patches
to Documentation/*.txt themselves, so that they are more consistent (and
incidentally nicer to the script).
Now, I hear you already moan: "But Dscho, you know you suck at Perl!"
Yeah, I know, but maybe instead of bashing on me (pun intended), you may
want to enlighten me with tips how to make it nicer to read. (Yes, there
are no comments; yes, I will gladly add them where appropriate; yes, html
is just a stub.)
So here, without further ado, da script:
-- snip --
#!/usr/bin/perl
$conv = new man_page();
$conv->{manual} = 'Git Manual';
$conv->{git_version} = 'Git ' . `cat ../GIT-VERSION-FILE`;
$conv->{git_version} =~ s/GIT_VERSION = //;
$conv->{git_version} =~ s/-/\\-/;
$conv->{git_version} =~ s/\n//;
$conv->{date} = `date +%m/%d/%Y`;
$conv->{date} =~ s/\n//;
$par = '';
handle_file($ARGV[0]);
$conv->finish();
sub handle_text {
if ($par =~ /^\. /s) {
my @lines = split(/^\. /m, $par);
shift @lines;
$conv->enumeration(\@lines);
} elsif ($par =~ /^\* /s) {
my @lines = split(/^\* /m, $par);
shift @lines;
$conv->enumeration(\@lines, 'unnumbered');
} elsif ($par =~ /^\[verse\]/) {
$par =~ s/\[verse\] *\n?//;
$conv->verse($par);
} elsif ($par =~ /^(\t| +)/s) {
$par =~ s/^$1//mg;
$par =~ s/^\+$//mg;
$conv->indent($par);
} elsif ($par =~ /^([^\n]*)::\n((\t| +).*)$/s) {
my ($first, $rest, $indent) = ($1, $2, $3);
$rest =~ s/^\+$//mg;
while ($rest =~ /^(.*?\n\n)--+\n(.*?\n)--+\n\n(.*)$/s) {
my ($pre, $verb, $post) = ($1, $2, $3);
$pre =~ s/^(\t|$indent)//mg;
if ($first ne '') {
$conv->begin_item($first, $pre);
$first = '';
} else {
$conv->normal($pre);
}
$conv->verbatim($verb);
$rest = $post;
}
$rest =~ s/^(\t|$indent)//mg;
if ($first ne '') {
$conv->begin_item($first, $rest);
} else {
$conv->normal($rest);
}
$conv->end_item();
} elsif ($par =~ /^-+\n(.*\n)-+\n$/s) {
$conv->verbatim($1);
} else {
$conv->normal($par);
}
$par = '';
}
sub handle_file {
my $in;
open($in, '<' . $_[0]);
while (<$in>) {
if (/^=+$/) {
if ($par ne '' && length($_) >= length($par)) {
$conv->header($par);
$par = '';
next;
}
} elsif (/^-+$/) {
if ($par ne '' && length($_) >= length($par)) {
$conv->section($par);
$par = '';
next;
}
} elsif (/^~+$/) {
if ($par ne '' && length($_) >= length($par)) {
$conv->subsection($par);
$par = '';
next;
}
} elsif (/^\[\[(.*)\]\]$/) {
handle_text();
$conv->anchor($1);
next;
} elsif (/^$/) {
if ($par =~ /^-+\n.*[^-]\n$/s) {
# fallthru; is verbatim, but needs more.
} elsif ($par =~ /::\n$/s) {
# is item, but needs more.
next;
} else {
handle_text();
next;
}
} elsif (/^include::(.*)\[\]$/) {
handle_text();
handle_file($1);
next;
}
# convert "\--" to "--"
s/\\--/--/g;
# convert "\*" to "*"
s/\\\*/*/g;
# handle gitlink:
s/gitlink:([^\[ ]*)\[(\d+)\]/sprintf "%s",
$conv->get_link($1, $2)/ge;
# handle link:
s/link:([^\[ ]*)\[(.+)\]/sprintf "%s",
$conv->get_link($1, $2, 'external')/ge;
$par .= $_;
}
close($in);
handle_text();
}
package man_page;
sub new {
my ($class) = @_;
my $self = {
sep => '',
links => [],
# generator => 'Home grown git txt2man converter'
generator => 'DocBook XSL Stylesheets v1.71.1 <http://docbook.sf.net/>'
};
bless $self, $class;
return $self;
}
sub header {
my ($self, $text) = @_;
$text =~ s/-/\\-/g;
if ($self->{preamble_shown} == undef) {
$title = $text;
$title =~ s/\(\d+\)$//;
print '.\" Title: ' . $title
. '.\" Author: ' . "\n"
. '.\" Generator: ' . $self->{generator} . "\n"
. '.\" Date: ' . $self->{date} . "\n"
. '.\" Manual: ' . $self->{manual} . "\n"
. '.\" Source: ' . $self->{git_version} . "\n"
. '.\"' . "\n";
}
$text =~ tr/a-z/A-Z/;
my $suffix = "\"$self->{date}\" \"$self->{git_version}\""
. " \"$self->{manual}\"";
$text =~ s/^(.*)\((\d+)\)$/.TH "\1" "\2" $suffix/;
print $text;
if ($self->{preamble_shown} == undef) {
print '.\" disable hyphenation' . "\n"
. '.nh' . "\n"
. '.\" disable justification (adjust text to left'
. ' margin only)' . "\n"
. '.ad l' . "\n";
$self->{preamble_shown} = 1;
}
$self->{last_op} = 'header';
}
sub section {
my ($self, $text) = @_;
$text =~ tr/a-z/A-Z/;
$text =~ s/^(.*)$/.SH "\1"/;
print $text;
$self->{last_op} = 'section';
}
sub subsection {
my ($self, $text) = @_;
$text =~ s/^(.*)$/.SS "\1"/;
print $text;
$self->{last_op} = 'subsection';
}
sub get_link {
my ($self, $command, $section, $option) = @_;
if ($option eq 'external') {
my $links = $self->{links};
push(@$links, $command);
$command =~ s/\.html$//;
$command =~ s/-/ /g;
push(@$links, $command);
return '\fI' . $command . '\fR\&[1]';
} else {
return '\fB' . $command . '\fR(' . $section . ')';
}
}
sub common {
my ($self, $text, $option) = @_;
# escape backslashes, but not in "\n", "\&" or "\fB"
$text =~ s/\\(?!n|f[A-Z]|&)/\\\\/g;
# escape "-"
$text =~ s/-/\\-/g;
# handle ...
$text =~ s/(\.\.\.)/\\&\1/g;
# remove double space after full stop or comma
$text =~ s/([\.,]) /\1 /g;
if ($option ne 'no-markup') {
# make 'italic'
$text =~ s/'([^'\n]*)'/\\fI\1\\fR/g;
# ignore `
$text =~ s/`//g;
# make *bold*
$text =~ s/\*([^\*\n]*)\*/\\fB\1\\fR/g;
# handle <<sections>
$text =~ s/<<([^>]*)>>/the section called \\(lq\1\\(rq/g;
}
return $text;
}
sub normal {
my ($self, $text) = @_;
if ($text eq "") {
return;
}
$text = $self->common($text);
$text =~ s/ *\n(.)/ \1/g;
if ($self->{last_op} eq 'normal') {
print "\n";
}
print $text;
$self->{last_op} = 'normal';
}
sub verse {
my ($self, $text) = @_;
$text = $self->common($text);
$text =~ s/^\t/ /mg;
print ".sp\n.RS 4\n.nf\n" . $text . ".fi\n.RE\n";
$self->{last_op} = 'verse';
}
sub enumeration {
my ($self, $text, $option) = @_;
my $counter = 0;
foreach $line (@$text) {
$counter++;
print ".TP 4\n"
. ($option eq 'unnumbered' ? '\(bu' : $counter . '.')
. "\n"
. $self->common($line);
}
$self->{last_op} = 'enumeration';
}
sub begin_item {
my ($self, $item, $text) = @_;
$item = $self->common($item);
$text = $self->common($text);
$text =~ s/([^\n]) *\n([^\n])/\1 \2/g;
print ".PP\n" . $item . "\n.RS 4\n" . $text;
$self->{last_op} = 'item';
}
sub end_item {
my ($self) = @_;
print ".RE\n";
$self->{last_op} = 'end_item';
}
sub indent {
my ($self, $text) = @_;
$text = $self->common($text, 'no-markup');
$text =~ s/^\t/ /mg;
if ($self->{last_op} eq 'normal') {
print "\n";
}
print ".sp\n.RS 4\n.nf\n" . $text . ".fi\n.RE\n";
$self->{last_op} = 'indent';
}
sub verbatim {
my ($self, $text) = @_;
$text = $self->common($text, 'no-markup');
# convert tabs to spaces
$text =~ s/^\t/ /mg;
# remove trailing empty lines
$text =~ s/\n\n*$/\n/;
if ($self->{last_op} eq 'normal') {
print "\n";
}
print ".sp\n.RS 4\n.nf\n.ft C\n" . $text . ".ft\n\n.fi\n.RE\n";
$self->{last_op} = 'verbatim';
}
sub anchor {
my ($self, $text) = @_;
$self->{last_op} = 'anchor';
}
sub finish {
my ($self) = @_;
my $links = $self->{links};
if ($#$links >= 0) {
print '.SH "REFERENCES"' . "\n";
my $i = 1;
while ($#$links >= 0) {
my $ref = shift(@$links);
$ref =~ s/-/\\-/g;
my $label = shift(@$links);
printf (".IP \"% 2d.\" 4\n%s\n.RS 4\n\\%%%s\n.RE\n",
$i++, $label, $ref);
}
} else {
print "\n";
}
}
package html_page;
sub new {
my ($class) = @_;
my $self = {};
bless $self, $class;
return $self;
}
-- snap --
Ciao,
Dscho
P.S.: I need to catch some Zs, and do some real work, so do not be
surprised if I do not respond within the next 24 hours.
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Junio C Hamano @ 2007-10-03 0:22 UTC (permalink / raw)
To: Jeff King; +Cc: Andy Parkins, git
In-Reply-To: <20071002204848.GA8284@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Perhaps a better quest would be to eliminate all of those counts
> entirely with code that is obviously correct. I think it is much more
> readable to replace:
>
> url = xmalloc(strlen(repo->base) + 64);
> sprintf(url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
>
> with something like:
>
> strbuf_init(&url);
> strbuf_addf(&url, "%s/objects/pack/pack-%s.idx", repo->base, hex);
Ugh, this typically calls snprintf() twice doesn't it?
^ permalink raw reply
* Re: [PATCH] Mention 'cpio' dependency in INSTALL
From: Junio C Hamano @ 2007-10-03 0:14 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Reece Dunn
In-Reply-To: <200710030142.30062.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> reveals that cpio is not mentioned anywhere in the documentation,
> nor in the requirements section of the INSTALL file.
Thanks.
We use many other tools that are typically found in bog-standard
UNIX environments, like sed, echo, cat, sort, etc. and we do not
list them in the INSTALL file (nor we would want to). cpio used
to be in the "bog standard" category but perhaps Linux distros
do not install it by default, so it is worth listing it there.
Are there other commands we rely on that may not be universally
installed? I myself consider "cut" to be in the category, but
other than that I do not think of anything offhand.
^ permalink raw reply
* [PATCH] Mention 'cpio' dependency in INSTALL
From: Johan Herland @ 2007-10-02 23:42 UTC (permalink / raw)
To: git; +Cc: Reece Dunn, Junio C Hamano
In-Reply-To: <3f4fd2640710021409q104a4204r522391912d5b5c8c@mail.gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
---
On Tuesday 02 October 2007, Reece Dunn wrote:
> Do you know if cpio is listed anywhere in required dependencies?
Doing the following in the git repo:
$ grep -r cpio *
git-clone.sh: find objects -depth -print | cpio -pumd$l "$GIT_DIR/" || exit 1
git-merge.sh: cpio -0 -o >"$GIT_DIR/MERGE_SAVE"
git-merge.sh: cpio -iuv <"$GIT_DIR/MERGE_SAVE"
reveals that cpio is not mentioned anywhere in the documentation,
nor in the requirements section of the INSTALL file.
Have fun!
...Johan
INSTALL | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/INSTALL b/INSTALL
index 289b046..f1eb404 100644
--- a/INSTALL
+++ b/INSTALL
@@ -79,6 +79,9 @@ Issues of note:
- "perl" and POSIX-compliant shells are needed to use most of
the barebone Porcelainish scripts.
+ - "cpio" is used by git-merge for saving and restoring the index,
+ and by git-clone when doing a local (possibly hardlinked) clone.
+
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
have all the libraries/tools needed, or you may have
--
1.5.3.3.1144.gf10f2
^ permalink raw reply related
* [PATCH 4/4] Make git-pull complain and give advice when there is nothing to pull from
From: Federico Mena Quintero @ 2007-10-02 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
git-pull.sh | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index c3f05f5..74bfc16 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -97,10 +97,24 @@ case "$merge_head" in
esac
curr_branch=${curr_branch#refs/heads/}
- echo >&2 "Warning: No merge candidate found because value of config option
- \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
- echo >&2 "No changes."
- exit 0
+ echo >&2 "You asked me to pull without telling me which branch you"
+ echo >&2 "want to merge with, and 'branch.${curr_branch}.merge' in"
+ echo >&2 "your configuration file does not tell me either. Please"
+ echo >&2 "name which branch you want to merge on the command line and"
+ echo >&2 "try again (e.g. 'git pull <repository> <refspec>')."
+ echo >&2 "See git-pull(1) for details on the refspec."
+ echo >&2
+ echo >&2 "If you often merge with the same branch, you may want to"
+ echo >&2 "configure the following variables in your configuration"
+ echo >&2 "file:"
+ echo >&2
+ echo >&2 " branch.${curr_branch}.remote = <nickname>"
+ echo >&2 " branch.${curr_branch}.merge = <remote-ref>"
+ echo >&2 " remote.<nickname>.url = <url>"
+ echo >&2 " remote.<nickname>.fetch = <refspec>"
+ echo >&2
+ echo >&2 "See git-config(1) for details."
+ exit 1
;;
?*' '?*)
if test -z "$orig_head"
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 1/4] Add documentation for --track and --no-track to the git-branch docs.
From: Federico Mena Quintero @ 2007-10-02 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191368010.3776.198.camel@cacharro.xalalinux.org>
Arrrr... this should be "[PATCH 2/4]", of course. Sorry for the
confusion.
Federico
^ permalink raw reply
* [PATCH 3/4] Note that git-branch will not automatically checkout the new branch
From: Federico Mena Quintero @ 2007-10-02 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
Documentation/git-branch.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index e9c12f9..53c1158 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -26,6 +26,10 @@ It will start out with a head equal to the one given as <start-point>.
If no <start-point> is given, the branch will be created with a head
equal to that of the currently checked out branch.
+Note that this will create the new branch, but it will not switch the
+working tree to it; use "git checkout <newbranch>" to switch to the
+new branch.
+
When a local branch is started off a remote branch, git can setup the
branch so that gitlink:git-pull[1] will appropriately merge from that
remote branch. If this behavior is desired, it is possible to make it
--
1.5.2.4
^ permalink raw reply related
* Re: metastore
From: Julian Phillips @ 2007-10-02 23:32 UTC (permalink / raw)
To: David Härdeman
Cc: David Kastrup, martin f krafft, git, Daniel Barkalow,
Johannes Schindelin, Thomas Harning Jr., Francis Moreau,
Nicolas Vilz
In-Reply-To: <20071002211518.GA10445@hardeman.nu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3128 bytes --]
On Tue, 2 Oct 2007, David Härdeman wrote:
> On Tue, Oct 02, 2007 at 10:04:56PM +0200, David Kastrup wrote:
>> David Härdeman <david@hardeman.nu> writes:
>>
>> > On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
>> > > also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
>> > > > But I agree, if any changes were made to git, I'd advocate adding
>> > > > arbitrary attributes to files (much like xattrs) in name=value
>> > > > pairs, then any extended metadata could be stored in those
>> > > > attributes and external scripts/tools could use them in some way
>> > > > that makes sense...and also make sure to only update them when it
>> > > > makes sense.
>> > >
>> > > So where would those metdata be stored in your opinion?
>> >
>> > I'm not sufficiently versed in the internals of git to have an
>> > informed opinion :)
>>
>> I think we have something like a length count for file names in index
>> and/or tree. We could just put the (sorted) attributes after a NUL
>> byte in the file name and include them in the count. It would also
>> make those artificially longer file names work more or less when
>> sorting them for deltification.
>
> Or perhaps the index format could be extended to include a new field for
> value=name pairs instead of overloading the name field.
>
> But as I said, I have no idea how feasible it would be to change git to
> support another arbitrary length field in the index/tree file.
>
>> However, this requires implementing _policies_: it must be possible to
>> specify per repository exactly what will and what won't get tracked,
>> or one will get conflicts that are not necessary or appropriate.
>
> I think the opposite approach would be better. Let git provide set/get/delete
> attribute operations and leave it at that. Then external programs can do what
> they want with that data and add/remove/modify tags as necessary (and also
> include the smarts to not, e.g. remove the permissions on all files if the
> git repo is checked out to a FAT fs).
You need more than that. You need to be able to log, blame etc on the
attributes. One of the big annoyances of Subversion properties is being
unable to find out when or why a property value was changed.
I still don't see why the attributes need to be stored in git directly -
particularly if you are going to use an external program to actually apply
any settings - why not store the attributes as normal file (or files) of
some sort tracked by git? You could use any number of methods - e.g. use
an sqlite database stored in the root of your tree, or a .<name>.props
file alongside each path that you have properties for. You could even
write a system that uses such a method and was then SCM agnostic, allowing
you to keep your attribute tracking system if/when something better than
git comes along - or simply share it with less-fortunate souls stuck in an
inferior system.
--
Julian
---
A strong conviction that something must be done is the parent of many
bad measures.
-- Daniel Webster
^ permalink raw reply
* [PATCH 1/4] Add documentation for --track and --no-track to the git-branch docs.
From: Federico Mena Quintero @ 2007-10-02 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
Documentation/git-branch.txt | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 33bc31b..e9c12f9 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -91,6 +91,21 @@ OPTIONS
--no-abbrev::
Display the full sha1s in output listing rather than abbreviating them.
+--track::
+ Set up configuration so that git-pull will automatically
+ retrieve data from the remote branch. Use this if you always
+ pull from the same remote branch into the new branch, or if you
+ don't want to use "git pull <repository> <refspec>" explicitly. Set the
+ branch.autosetupmerge configuration variable to true if you
+ want git-checkout and git-branch to always behave as if
+ '--track' were given.
+
+--no-track::
+ When -b is given and a branch is created off a remote branch,
+ set up configuration so that git-pull will not retrieve data
+ from the remote branch, ignoring the branch.autosetupmerge
+ configuration variable.
+
<branchname>::
The name of the branch to create or delete.
The new branch name must pass all checks defined by
--
1.5.2.4
^ permalink raw reply related
* [PATCH 1/4] Say when --track is useful in the git-checkout docs.
From: Federico Mena Quintero @ 2007-10-02 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1191367817.3776.192.camel@cacharro.xalalinux.org>
The documentation used to say what the option does, but it
didn't mention a use case.
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
Documentation/git-checkout.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 734928b..dbd1a4a 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -50,7 +50,9 @@ OPTIONS
--track::
When -b is given and a branch is created off a remote branch,
set up configuration so that git-pull will automatically
- retrieve data from the remote branch. Set the
+ retrieve data from the remote branch. Use this if you always
+ pull from the same remote branch into the new branch, or if you
+ don't want to use "git pull <repository> <refspec>" explicitly. Set the
branch.autosetupmerge configuration variable to true if you
want git-checkout and git-branch to always behave as if
'--track' were given.
--
1.5.2.4
^ permalink raw reply related
* [PATCH 0/4] Another round of the --track patches
From: Federico Mena Quintero @ 2007-10-02 23:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3axbvbto.fsf@gitster.siamese.dyndns.org>
On Tue, 2007-09-18 at 15:38 -0700, Junio C Hamano wrote:
> Federico Mena Quintero <federico@novell.com> writes:
> > - retrieve data from the remote branch. Set the
> > + retrieve data from the remote branch, otherwise you'll have to
> > + use "git pull <url>" explicitly. Set the
> > branch.autosetupmerge configuration variable to true if you
> > want git-checkout and git-branch to always behave as if
> > '--track' were given.
>
> Hmph.
>
> I'd rather make them consistent by dropping the not-so-correct
> "otherwise" phrase from all three copies. It is not "otherwise
> you'll have to", but "instead you can".
Sure, I've added better wording now.
> I am inclined to suggest rewording the message like this, and
> make this condition an error (i.e. "exit 1"):
[snip]
I like that message much better, and it's nice that it gives you the
snippet to put in your config file. This is in patch 4/4.
Thanks for the review; I hope this can make it in now ;)
Federico
^ 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