* 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: Dan Zwell @ 2007-10-03 4:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Martin Waitz, Linus Torvalds
In-Reply-To: <20071003032331.GA11638@coredump.intra.peff.net>
Jeff King wrote:
> 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?
>
You're absolutely right, my pager was being called and exiting. My
system configuration must be dodgy, because "echo hi | less
--quit-if-one-screen" does not display anything unless it in run in
"screen". But that's not git's fault, and I just need different options,
for now. Thanks a lot for helping me solve this.
Dan
>
> -Peff
>
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Johannes Schindelin @ 2007-10-03 4:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Andy Parkins, git
In-Reply-To: <20071003025853.GA11440@coredump.intra.peff.net>
Hi,
On Tue, 2 Oct 2007, Jeff King wrote:
> 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?
I wonder, I wonder, if
strbuf_addstr(&url, repo->base);
strbuf_addstr(&url, "/objects/pack/pack-");
strbuf_addstr(&url, hex);
strbuf_addstr(&url, ".idx");
would make anybody else but me happy...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] diffcore-rename: cache file deltas
From: Junio C Hamano @ 2007-10-03 4:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.0.999.0710021832520.3579@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> 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.
Thanks.
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Johannes Schindelin @ 2007-10-03 4:23 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, msysgit
In-Reply-To: <4702F6BB.60908@vilain.net>
Hi,
On Wed, 3 Oct 2007, Sam Vilain wrote:
> Johannes Schindelin wrote:
>
> > I do not want to depend on more than necessary in msysGit, and
> > therefore I started to write an asciidoc replacement.
>
> It's pretty good, I certainly wouldn't have trouble reading or
> maintaining it, but I'll give you suggestions anyway.
Thank you very much! (On both accounts...)
> nice work, replacing a massive XML/XSL/etc stack with a small Perl
> script ;-)
Uhm... It is less capable, though...
> > -- snip --
> > #!/usr/bin/perl
>
> Add -w for warnings, also use strict;
<dumb>What does "use strict;" imply?</dumb>
> > sub handle_text {
>
> this function acts on globals; make them explicit arguments to the
> function.
Actually, it resets the global $par. Should I rather make it a class?
> > if ($par =~ /^\. /s) {
> > my @lines = split(/^\. /m, $par);
> > shift @lines;
> > $conv->enumeration(\@lines);
> > } elsif ($par =~ /^\* /s) {
>
> uncuddle your elsif's;
I'm sorry... What do you mean?
> 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) :
> ... )
I do not like that way... is it Perl standard to code like that?
> 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?
I wanted to keep it simple. So I'll try to stay away from any fancy
grammar parsing, and stay with "read lines until you have something to
process".
> > # 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.
I guess you mean the forward slash. Alas, that's what I'm used to, and
I'd rather not change it unless forced to... lest I stop understanding my
own code!
(Besides, I did not find _any_ example showing why "x" should be useful.)
> > 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.
Can you give me an example of a HERE-doc? (What I tried to avoid is
having ugly indentation-breaking tlobs.)
> > $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.
I'll try to find something about qq{} in the docs.
> > $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 :)
Does that also work with older perl? IIRC there was some strange problem
with my perl when lots of code in git.git was changed to using commata.
> > # 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 <<((?:[^>]+|>[^>])*)>>
I'd rather leave it as is -- this script is not meant to grok all kind of
sh*t. It is meant to make translating the docs as fast and uncumbersome
as possible. Which will involve making the documentation more consistent
(in and of itself something I rather like).
So unless there comes a compelling reason, I'd rather leave it.
> > 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).
But I need the (implicit) 's' modifier, otherwise the "\n" in the middle
is not interpreted correctly. This regsub is meant to unwrap the
paragraph and put it into a very long line (but leaving \n\n alone).
> > 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)
Thanks. I hoped there would be something like this.
Another thing: if I want to add some documentation, what would be the
common way to do it? =pod...=cut?
Thank you for all your tips!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change "refs/" references to symbolic constants
From: Jeff King @ 2007-10-03 4:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andy Parkins, git
In-Reply-To: <Pine.LNX.4.64.0710030503520.28395@racer.site>
On Wed, Oct 03, 2007 at 05:05:15AM +0100, Johannes Schindelin wrote:
> I wonder, I wonder, if
>
> strbuf_addstr(&url, repo->base);
> strbuf_addstr(&url, "/objects/pack/pack-");
> strbuf_addstr(&url, hex);
> strbuf_addstr(&url, ".idx");
>
> would make anybody else but me happy...
I actually wrote that originally, and then switched to the formatted
version for readability. But I would be happy with that, as well, if we
are truly concerned about the cost of 2 snprintfs.
-Peff
^ permalink raw reply
* Re: git-diff not showing changes (corrupt repo?)
From: Jeff King @ 2007-10-03 4:38 UTC (permalink / raw)
To: Dan Zwell; +Cc: Junio C Hamano, git, Martin Waitz, Linus Torvalds
In-Reply-To: <470313D0.7020808@gmail.com>
On Tue, Oct 02, 2007 at 11:00:16PM -0500, Dan Zwell wrote:
> You're absolutely right, my pager was being called and exiting. My system
> configuration must be dodgy, because "echo hi | less --quit-if-one-screen"
> does not display anything unless it in run in "screen". But that's not git's
This is obviously getting into less debugging (about which I know
little), but it's possible that you have a bogus TERM setting.
> fault, and I just need different options, for now. Thanks a lot for helping
> me solve this.
Thank you for providing such helpful details. It really makes a
difference.
-Peff
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Junio C Hamano @ 2007-10-03 4:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710030133020.28395@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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).
How you spend your time is up to you, but I need to wonder...
- Is "man" format important for msysGit aka Windows
environment? I had an impression that their helpfile format
were closer to "html" output.
- Does it make sense in the longer term for us to maintain
in-house documentation tools? Can we afford it?
It appears that we heard about breakages for every minor docbook
updates, and it is really appealing if we do not have to rely on
xsl toolchain for manpage generation. But if patching the text
means making it compatible with the in-house script _and_
incompatible with AsciiDoc, hmmm...
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Jeff King @ 2007-10-03 4:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, git, msysgit
In-Reply-To: <Pine.LNX.4.64.0710030506360.28395@racer.site>
On Wed, Oct 03, 2007 at 05:23:35AM +0100, Johannes Schindelin wrote:
> > > #!/usr/bin/perl
> >
> > Add -w for warnings, also use strict;
>
> <dumb>What does "use strict;" imply?</dumb>
Try "perldoc strict" for details.
> > > if ($par =~ /^\. /s) {
> > > my @lines = split(/^\. /m, $par);
> > > shift @lines;
> > > $conv->enumeration(\@lines);
> > > } elsif ($par =~ /^\* /s) {
> >
> > uncuddle your elsif's;
>
> I'm sorry... What do you mean?
I think he means reformatting to
if (condition) {
}
elsif (condition) {
}
> > $result = ( $par =~ /^\. /s ? $conv->do_enum($par) :
> > $par =~ /^\[verse\]/ ? $conv->do_verse($par) :
> > ... )
>
> I do not like that way... is it Perl standard to code like that?
It's quite common if you have a dispatch function, but obviously not
required.
> > > $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.
>
> Can you give me an example of a HERE-doc? (What I tried to avoid is
> having ugly indentation-breaking tlobs.)
print <<EOF;
foo
EOF
HERE-docs necessarily break indentation unless you strip it out manually
(which is inefficient and ugly).
But two things that might make that look better are using qq// (to avoid
having to escape quotes) and interpolating the variables:
. qq/." Generator: $self->{generator}\n/
> I'll try to find something about qq{} in the docs.
It's in perlop, but it's basically a fancy way of double-quoting, except
that you get to choose the delimiter.
> > > $text =~ s/([^\n]) *\n([^\n])/\1 \2/g;
> >
> > "." is the same as [^\n] (without the 's' modifier).
>
> But I need the (implicit) 's' modifier, otherwise the "\n" in the middle
> is not interpreted correctly. This regsub is meant to unwrap the
> paragraph and put it into a very long line (but leaving \n\n alone).
I think you might be confused about how the 's' modifier works. You are
not using it, so '.' is the same as '[^\n]'. Perl will always match a
newline if it's in your regex. If you specify 'm', then it will also
allow '^' and '$' to match at line boundaries (instead of just at the
beginning and end of the string).
-Peff
^ permalink raw reply
* Re: [PATCH] the ar tool is called gar on some systems
From: Junio C Hamano @ 2007-10-03 4:55 UTC (permalink / raw)
To: Robert Schiele; +Cc: git
In-Reply-To: <20071003014934.GF20753@schiele.dyndns.org>
Robert Schiele <rschiele@gmail.com> writes:
> 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.
I still have the original one in my mailbox. Hasn't applied as
we hadn't heard anybody cheering or thanking for the patch, but
I do not see anything _wrong_ with it, so let's apply.
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Miles Bader @ 2007-10-03 5:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7v3awzvrpr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think it is sensible to have an option to make it push only the
> current branch. I am not sure if it is sensible to make that the
> default.
I really like the current default, it matches my mental model well: I
generally use "push" to mean "synchronize the remote repository with my
current one"; if multiple branches have changed, I want those changes
propagated too.
I think changing it would be a bad idea, it just seems a pointlessly
incompatible change. The reasons I've seen offered on this thread for
changing the default seem pretty weak, e.g., "it's more conservative"
(but more annoying), and "it's more like SVK" (who cares?).
-Miles
--
Freedom's just another word, for nothing left to lose --Janis Joplin
^ permalink raw reply
* Clone corruption to G4 MacOSX
From: Perry Wagle @ 2007-10-03 4:29 UTC (permalink / raw)
To: git
I have a G4 iBook running MacOSX 10.4.10. If I build the most recent
production git (git-1.5.3.2) from the tarball from the git website, I
get a corrupt copy of Linus's kernel repository (git://git.kernel.org/
pub/scm/linux/kernel/git/torvalds/linux-2.6.git) when I try to clone
it. Specifically, my copy is missing several files, including ./
include/linux/netfilter/xt_CONNMARK.h. The involved files seem to be:
include/linux/netfilter/xt_CONNMARK.h
include/linux/netfilter/xt_DSCP.h
include/linux/netfilter/xt_MARK.h
include/linux/netfilter/xt_TCPMSS.h
include/linux/netfilter_ipv4/ipt_CONNMARK.h
include/linux/netfilter_ipv4/ipt_DSCP.h
include/linux/netfilter_ipv4/ipt_ECN.h
include/linux/netfilter_ipv4/ipt_MARK.h
include/linux/netfilter_ipv4/ipt_TCPMSS.h
include/linux/netfilter_ipv4/ipt_TOS.h
include/linux/netfilter_ipv4/ipt_TTL.h
include/linux/netfilter_ipv6/ip6t_HL.h
include/linux/netfilter_ipv6/ip6t_MARK.h
net/ipv4/netfilter/ipt_ECN.c
net/ipv4/netfilter/ipt_TOS.c
net/ipv4/netfilter/ipt_TTL.c
net/ipv6/netfilter/ip6t_HL.c
net/netfilter/xt_CONNMARK.c
net/netfilter/xt_DSCP.c
net/netfilter/xt_MARK.c
net/netfilter/xt_TCPMSS.c
I first noticed this corruption around August 14, 2007, when it
seemed to be in the head of the clone of Linus's repository. I was
able to make it go away by committing the HEAD. I was just starting
with git, and figured I got some incomplete copy because Linus was in
the middle of something. Now I cannot find any commits for
xt_CONNMARK.h or xt_connmark.h since 2006, especially around August
14, but that might be my naivete.
If I clone Linus's repository to a x86 machine, I get no corruption.
My wild ass guess is that being big-endian is causing trouble.
-- Perry
^ permalink raw reply
* Re: Clone corruption to G4 MacOSX
From: Kyle McMartin @ 2007-10-03 5:28 UTC (permalink / raw)
To: Perry Wagle; +Cc: git
In-Reply-To: <82638874-6766-4DCD-BF5B-3893F9B5046F@cs.indiana.edu>
On Tue, Oct 02, 2007 at 09:29:07PM -0700, Perry Wagle wrote:
> If I clone Linus's repository to a x86 machine, I get no corruption.
>
> My wild ass guess is that being big-endian is causing trouble.
>
The problem is MacOSX uses a case-insensitive filesystem by default...
Cheers,
Kyle
^ permalink raw reply
* [PATCH] rebase: make the warning more useful when the work tree is unclean.
From: Junio C Hamano @ 2007-10-03 5:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Steffen Prohaska
In-Reply-To: <7vd4vxmmxr.fsf@gitster.siamese.dyndns.org>
Instead of letting "update-index --refresh" report paths needing
updates and merges, use git-status to give more useful output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I won't be a good judge of the updated behaviour, as I never
start rebase in an unclear tree. Running git-status in a
large tree may be too expensive to be worth changing the
output.
git-rebase.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 1583402..93e3b3c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -254,7 +254,11 @@ else
fi
# The tree must be really really clean.
-git update-index --refresh || exit
+git update-index -q --refresh || {
+ git status
+ printf "cannot rebase: the work tree is not clean.\n"
+ exit 1
+}
diff=$(git diff-index --cached --name-status -r HEAD)
case "$diff" in
?*) echo "cannot rebase: your index is not up-to-date"
--
1.5.3.3.1144.gf10f2
^ permalink raw reply related
* Re: git push (mis ?)behavior
From: Junio C Hamano @ 2007-10-03 5:39 UTC (permalink / raw)
To: Miles Bader; +Cc: Pierre Habouzit, git
In-Reply-To: <buoprzwn5qm.fsf@dhapc248.dev.necel.com>
Miles Bader <miles.bader@necel.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>> I think it is sensible to have an option to make it push only the
>> current branch. I am not sure if it is sensible to make that the
>> default.
>
> I really like the current default, it matches my mental model well: I
> generally use "push" to mean "synchronize the remote repository with my
> current one"; if multiple branches have changed, I want those changes
> propagated too.
>
> I think changing it would be a bad idea, it just seems a pointlessly
> incompatible change. The reasons I've seen offered on this thread for
> changing the default seem pretty weak, e.g., "it's more conservative"
> (but more annoying), and "it's more like SVK" (who cares?).
Usually we hear people complain louder on the list.
People who are happy with the existing behaviour tend to be
quiet, and we should be really careful not to break things for
silent majority.
I try to stay fairly conservative, often more conservative than
what I would like to be myself, for this exact reason.
^ permalink raw reply
* Re: Clone corruption to G4 MacOSX
From: Junio C Hamano @ 2007-10-03 5:44 UTC (permalink / raw)
To: Perry Wagle; +Cc: git
In-Reply-To: <82638874-6766-4DCD-BF5B-3893F9B5046F@cs.indiana.edu>
Perry Wagle <wagle@cs.indiana.edu> writes:
> include/linux/netfilter/xt_CONNMARK.h. The involved files seem to be:
>
> include/linux/netfilter/xt_CONNMARK.h
> include/linux/netfilter/xt_DSCP.h
> include/linux/netfilter/xt_MARK.h
> include/linux/netfilter/xt_TCPMSS.h
> include/linux/netfilter_ipv4/ipt_CONNMARK.h
> include/linux/netfilter_ipv4/ipt_DSCP.h
> include/linux/netfilter_ipv4/ipt_ECN.h
> include/linux/netfilter_ipv4/ipt_MARK.h
> include/linux/netfilter_ipv4/ipt_TCPMSS.h
> include/linux/netfilter_ipv4/ipt_TOS.h
> include/linux/netfilter_ipv4/ipt_TTL.h
> include/linux/netfilter_ipv6/ip6t_HL.h
> include/linux/netfilter_ipv6/ip6t_MARK.h
> net/ipv4/netfilter/ipt_ECN.c
> net/ipv4/netfilter/ipt_TOS.c
> net/ipv4/netfilter/ipt_TTL.c
> net/ipv6/netfilter/ip6t_HL.c
> net/netfilter/xt_CONNMARK.c
> net/netfilter/xt_DSCP.c
> net/netfilter/xt_MARK.c
> net/netfilter/xt_TCPMSS.c
>
> I first noticed this corruption around August 14, 2007, when it seemed
> ...
>
> If I clone Linus's repository to a x86 machine, I get no corruption.
>
> My wild ass guess is that being big-endian is causing trouble.
Is the filesystem HFS+ that is case-losing?
^ permalink raw reply
* [PATCH] Must not modify the_index.cache as it may be passed to realloc at some point.
From: Keith Packard @ 2007-10-03 5:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: keithp
[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]
The index cache is not static, growing as new entries are added. If entries
are added after prune_cache is called, cache will no longer point at the
base of the allocation, and realloc will not be happy.
I verified that this was the only place in the current source which modified
any index_state.cache elements aside from the alloc/realloc calls in read-cache by
changing the type of the element to 'struct cache_entry ** const cache' and
recompiling.
A more efficient patch would create a separate 'cache_base' value to track
the allocation and then fix things up when reallocation was necessary,
instead of the brute-force memmove used here.
---
builtin-ls-files.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 6c1db86..0028b8a 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -280,7 +280,7 @@ static void prune_cache(const char *prefix)
if (pos < 0)
pos = -pos-1;
- active_cache += pos;
+ memmove (active_cache, active_cache + pos, (active_nr - pos) * sizeof (struct cache_entry *));
active_nr -= pos;
first = 0;
last = active_nr;
--
1.5.3.3.131.g34c6d-dirty
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: Clone corruption to G4 MacOSX
From: Perry Wagle @ 2007-10-03 5:50 UTC (permalink / raw)
To: Kyle McMartin; +Cc: git
In-Reply-To: <20071003052834.GC13738@fattire.cabal.ca>
Yeah, that'd be it. Thanks!
-- Perry
On Oct 2, 2007, at 10:28 PM, Kyle McMartin wrote:
> On Tue, Oct 02, 2007 at 09:29:07PM -0700, Perry Wagle wrote:
>> If I clone Linus's repository to a x86 machine, I get no corruption.
>>
>> My wild ass guess is that being big-endian is causing trouble.
>>
>
> The problem is MacOSX uses a case-insensitive filesystem by default...
>
> Cheers,
> Kyle
> -
> 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
* Re: [PATCH] Must not modify the_index.cache as it may be passed to realloc at some point.
From: Junio C Hamano @ 2007-10-03 5:55 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1191390255.16292.2.camel@koto.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> The index cache is not static, growing as new entries are added. If entries
> are added after prune_cache is called, cache will no longer point at the
> base of the allocation, and realloc will not be happy.
Thanks for catching this. This code originally was perfectly
Ok, but I broke it with the overlay_tree() change.
^ permalink raw reply
* Re: [PATCH] Mention 'cpio' dependency in INSTALL
From: Chris Larson @ 2007-10-03 6:09 UTC (permalink / raw)
To: git
In-Reply-To: <7v1wcdjbq6.fsf@gitster.siamese.dyndns.org>
On 10/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
I'd think it might be a good idea to list any utilities used that
aren't in, say, the Single Unix Specification, for example.
--
Chris Larson - clarson at kergoth dot com
Software Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Wincent Colaiuta @ 2007-10-03 6:40 UTC (permalink / raw)
To: Sam Vilain; +Cc: Johannes Schindelin, git, msysgit
In-Reply-To: <4702F6BB.60908@vilain.net>
El 3/10/2007, a las 3:56, Sam Vilain escribió:
> 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?
I haven't looked at all of the asciidoc source for the Git
documentation but I suspect that almost all of it is entirely
regular, and if there is any nesting in it is is probably of a
limited scope (ie. sections, subsections, subsubsections in the user
manual) and so you can avoid the complexity of a full recursive
descent parser. I'd also expect Johannes' approach to be faster (is
it faster than the existing tool chain? I would expect so).
Cheers,
Wincent
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Wincent Colaiuta @ 2007-10-03 6:47 UTC (permalink / raw)
To: Miles Bader; +Cc: Junio C Hamano, Pierre Habouzit, git
In-Reply-To: <buoprzwn5qm.fsf@dhapc248.dev.necel.com>
El 3/10/2007, a las 7:10, Miles Bader escribió:
> Junio C Hamano <gitster@pobox.com> writes:
>> I think it is sensible to have an option to make it push only the
>> current branch. I am not sure if it is sensible to make that the
>> default.
>
> I really like the current default, it matches my mental model well: I
> generally use "push" to mean "synchronize the remote repository
> with my
> current one"; if multiple branches have changed, I want those changes
> propagated too.
>
> I think changing it would be a bad idea, it just seems a pointlessly
> incompatible change. The reasons I've seen offered on this thread for
> changing the default seem pretty weak, e.g., "it's more conservative"
> (but more annoying)
It could be more annoying for some, yet a life saver for others. So
before changing the default obviously we would need to get a clear
idea of whether or not the majority would approve of such a move.
Such differences of opinion would be easily accommodated if the
default behaviour were made configurable. That way everyone can have
the behaviour they want.
Cheers,
Wincent
PS. I'm the one who mentioned SVK, but I didn't offer it as a reason
to justify the change (I agree, more than "weak" it's not really any
reason at all); I just mentioned to indicate why it is that the
current behaviour caught me off guard.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-10-03 6:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Kastrup, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0710021916080.3579@woody.linux-foundation.org>
On Tue, Oct 02, 2007 at 07:28:19PM -0700, Linus Torvalds wrote:
> 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..
I get slightly better speedups with my pathological case (around 30%):
Before:
$ /usr/bin/time git-diff --raw -M -l0 06d288^ 06d288 >/dev/null
105.38user 3.65system 2:14.90elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (15432major+542627minor)pagefaults 0swaps
After:
$ /usr/bin/time git-diff --raw -M -l0 06d288^ 06d288 >/dev/null
71.70user 3.47system 1:40.43elapsed 74%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (15065major+551778minor)pagefaults 0swaps
But yes, it's not the order of magnitude we were looking for.
> [torvalds@woody linux]$ time git diff -l0 --stat -C v2.6.22.. | wc
I found less noise in the timing by using --raw, since the patch
computation takes an appreciable amount of time.
> 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.
Patch looks correct, and it produces correct results on my (admittedly
limited) test data.
I think it's worth applying (though I agree that a comment on the
assumption of a zero "cnt" at the end is worth adding) unless some
drastically different solution comes along (e.g., David's idea to try
avoiding the outer O(n^2) loop). But I don't think there is much more to
be gained from a different approach to comparing the two hash tables.
-Peff
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Wincent Colaiuta @ 2007-10-03 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, msysgit
In-Reply-To: <7vprzwhkgd.fsf@gitster.siamese.dyndns.org>
El 3/10/2007, a las 6:48, Junio C Hamano escribió:
> - Does it make sense in the longer term for us to maintain
> in-house documentation tools? Can we afford it?
>
> It appears that we heard about breakages for every minor docbook
> updates, and it is really appealing if we do not have to rely on
> xsl toolchain for manpage generation.
Indeed, especially seeing as asciidoc and the xsl toolchain are the
trickiest build dependencies to install. If all that could be
replaced by a single simple script like this one then that would be
awesome, and probably more maintainable in the long run seeing as it
would eliminate those intermittent breakages caused by changes in
third-party tools.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Add test case for ls-files --with-head
From: Carl Worth @ 2007-10-03 7:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <7vtzp8g2s2.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]
This tests basic functionality and also exercises a bug noticed
by Keith Packard, (prune_cache followed by add_index_entry can
trigger an attempt to realloc a pointer into the middle of an
allocated buffer).
---
t/t3060-ls-files-with-head.sh | 53 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
create mode 100755 t/t3060-ls-files-with-head.sh
On Tue, 02 Oct 2007 22:55:57 -0700, Junio C Hamano wrote:
>
> Thanks for catching this. This code originally was perfectly
> Ok, but I broke it with the overlay_tree() change.
Yeah, Keith and I were really scratching our heads as to how this
hadn't caused more problems earlier. I wrote the test case below to
explore the issue and found the recent overlay_tree change as you
mention, and that made more sense.
I didn't notice any existing --with-tree test case, so perhaps the
patch below is useful.
-Carl
diff --git a/t/t3060-ls-files-with-head.sh b/t/t3060-ls-files-with-head.sh
new file mode 100755
index 0000000..4ead08b
--- /dev/null
+++ b/t/t3060-ls-files-with-head.sh
@@ -0,0 +1,53 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Carl D. Worth
+#
+
+test_description='git ls-files test (--with-head).
+
+This test runs git ls-files --with-head and in particular in
+a scenario known to trigger a crash with some versions of git.
+'
+. ./test-lib.sh
+
+# The bug we're exercising requires a fair number of entries in a
+# sub-directory so that add_index_entry will trigger a realloc
+echo file > expected
+mkdir sub
+for num in $(seq -f%04g 1 50); do
+ touch sub/file-$num
+ echo file-$num >> expected
+done
+git add .
+git commit -m "add a bunch of files"
+
+# We remove them all so that we'll have something to add back with
+# --with-head and so that we'll definitely be under the realloc size
+# to trigger the bug.
+rm -r sub
+git commit -a -m "remove them all"
+
+# The bug also requires some entry before our directory so that
+# prune_path will modify the_index.cache
+mkdir a_directory_that_sorts_before_sub
+touch a_directory_that_sorts_before_sub/file
+mkdir sub
+touch sub/file
+git add .
+
+# We have to run from a sub-directory to trigger prune_path
+cd sub
+
+# Then we finally get to run our --with-tree test
+test_expect_success \
+ 'git -ls-files --with-tree should succeed.' \
+ 'git ls-files --with-tree=HEAD~1 >../output'
+
+cd ..
+test_expect_success \
+ 'git -ls-files --with-tree should add entries from named tree.' \
+ 'diff output expected'
+
+test_done
+
+
--
1.5.3.3.131.g34c6d
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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