* [PATCH] improve index-pack tests
From: Nicolas Pitre @ 2008-10-23 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Commit 9441b61dc5 introduced serious bugs in index-pack which are
described and fixed by commit ce3f6dc655. However, despite the
boldness of those bugs, the test suite still passed.
This improves t5302-pack-index.sh so to ensure a much better code
path coverage. With commit ce3f6dc655 reverted, 17 of the 26 tests
do fail now.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index 344ab25..b0b0fda 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -11,13 +11,18 @@ test_expect_success \
'rm -rf .git
git init &&
i=1 &&
- while test $i -le 100
+ while test $i -le 100
do
- i=`printf '%03i' $i`
- echo $i >file_$i &&
- test-genrandom "$i" 8192 >>file_$i &&
- git update-index --add file_$i &&
- i=`expr $i + 1` || return 1
+ iii=`printf '%03i' $i`
+ test-genrandom "bar" 200 > wide_delta_$iii &&
+ test-genrandom "baz $iii" 50 >> wide_delta_$iii &&
+ test-genrandom "foo"$i 100 > deep_delta_$iii &&
+ test-genrandom "foo"`expr $i + 1` 100 >> deep_delta_$iii &&
+ test-genrandom "foo"`expr $i + 2` 100 >> deep_delta_$iii &&
+ echo $iii >file_$iii &&
+ test-genrandom "$iii" 8192 >>file_$iii &&
+ git update-index --add file_$iii deep_delta_$iii wide_delta_$iii &&
+ i=`expr $i + 1` || return 1
done &&
{ echo 101 && test-genrandom 100 8192; } >file_101 &&
git update-index --add file_101 &&
@@ -92,6 +97,31 @@ test_expect_success \
'64-bit offsets: index-pack result should match pack-objects one' \
'cmp "test-3-${pack3}.idx" "3.idx"'
+# returns the object number for given object in given pack index
+index_obj_nr()
+{
+ idx_file=$1
+ object_sha1=$2
+ nr=0
+ git show-index < $idx_file |
+ while read offs sha1 extra
+ do
+ nr=$(($nr + 1))
+ test "$sha1" = "$object_sha1" || continue
+ echo "$(($nr - 1))"
+ break
+ done
+}
+
+# returns the pack offset for given object as found in given pack index
+index_obj_offset()
+{
+ idx_file=$1
+ object_sha1=$2
+ git show-index < $idx_file | grep $object_sha1 |
+ ( read offs extra && echo "$offs" )
+}
+
test_expect_success \
'[index v1] 1) stream pack to repository' \
'git index-pack --index-version=1 --stdin < "test-1-${pack1}.pack" &&
@@ -102,19 +132,22 @@ test_expect_success \
test_expect_success \
'[index v1] 2) create a stealth corruption in a delta base reference' \
- '# this test assumes a delta smaller than 16 bytes at the end of the pack
- git show-index <1.idx | sort -n | sed -ne \$p | (
- read delta_offs delta_sha1 &&
- git cat-file blob "$delta_sha1" > blob_1 &&
- chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
- dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($delta_offs + 1)) \
- if=".git/objects/pack/pack-${pack1}.idx" skip=$((256 * 4 + 4)) \
- bs=1 count=20 conv=notrunc &&
- git cat-file blob "$delta_sha1" > blob_2 )'
+ '# This test assumes file_101 is a delta smaller than 16 bytes.
+ # It should be against file_100 but we substitute its base for file_099
+ sha1_101=`git hash-object file_101` &&
+ sha1_099=`git hash-object file_099` &&
+ offs_101=`index_obj_offset 1.idx $sha1_101` &&
+ nr_099=`index_obj_nr 1.idx $sha1_099` &&
+ chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
+ dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \
+ if=".git/objects/pack/pack-${pack1}.idx" \
+ skip=$((4 + 256 * 4 + $nr_099 * 24)) \
+ bs=1 count=20 conv=notrunc &&
+ git cat-file blob $sha1_101 > file_101_foo1'
test_expect_success \
'[index v1] 3) corrupted delta happily returned wrong data' \
- '! cmp blob_1 blob_2'
+ 'test -f file_101_foo1 && ! cmp file_101 file_101_foo1'
test_expect_success \
'[index v1] 4) confirm that the pack is actually corrupted' \
@@ -140,19 +173,22 @@ test_expect_success \
test_expect_success \
'[index v2] 2) create a stealth corruption in a delta base reference' \
- '# this test assumes a delta smaller than 16 bytes at the end of the pack
- git show-index <1.idx | sort -n | sed -ne \$p | (
- read delta_offs delta_sha1 delta_crc &&
- git cat-file blob "$delta_sha1" > blob_3 &&
- chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
- dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($delta_offs + 1)) \
- if=".git/objects/pack/pack-${pack1}.idx" skip=$((8 + 256 * 4)) \
- bs=1 count=20 conv=notrunc &&
- git cat-file blob "$delta_sha1" > blob_4 )'
+ '# This test assumes file_101 is a delta smaller than 16 bytes.
+ # It should be against file_100 but we substitute its base for file_099
+ sha1_101=`git hash-object file_101` &&
+ sha1_099=`git hash-object file_099` &&
+ offs_101=`index_obj_offset 1.idx $sha1_101` &&
+ nr_099=`index_obj_nr 1.idx $sha1_099` &&
+ chmod +w ".git/objects/pack/pack-${pack1}.pack" &&
+ dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \
+ if=".git/objects/pack/pack-${pack1}.idx" \
+ skip=$((8 + 256 * 4 + $nr_099 * 20)) \
+ bs=1 count=20 conv=notrunc &&
+ git cat-file blob $sha1_101 > file_101_foo2'
test_expect_success \
'[index v2] 3) corrupted delta happily returned wrong data' \
- '! cmp blob_3 blob_4'
+ 'test -f file_101_foo2 && ! cmp file_101 file_101_foo2'
test_expect_success \
'[index v2] 4) confirm that the pack is actually corrupted' \
@@ -167,9 +203,11 @@ test_expect_success \
'rm -f .git/objects/pack/* &&
git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git verify-pack ".git/objects/pack/pack-${pack1}.pack" &&
+ obj=`git hash-object file_001` &&
+ nr=`index_obj_nr ".git/objects/pack/pack-${pack1}.idx" $obj` &&
chmod +w ".git/objects/pack/pack-${pack1}.idx" &&
dd if=/dev/zero of=".git/objects/pack/pack-${pack1}.idx" conv=notrunc \
- bs=1 count=4 seek=$((8 + 256 * 4 + `wc -l <obj-list` * 20 + 0)) &&
+ bs=1 count=4 seek=$((8 + 256 * 4 + `wc -l <obj-list` * 20 + $nr * 4)) &&
( while read obj
do git cat-file -p $obj >/dev/null || exit 1
done <obj-list ) &&
^ permalink raw reply related
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: David Symonds @ 2008-10-23 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vvdvkte4i.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 22, 2008 at 4:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
> By the way, are you still in need of a folding bookshelf from Target?
Weirdest aside *ever* on the Git ML, at least from my memory.
Dave.
^ permalink raw reply
* Re: [RFC PATCH 1/5] add valgrind support in test scripts
From: Junio C Hamano @ 2008-10-23 0:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0810230008430.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 22 Oct 2008, Jeff King wrote:
>
>> diff --git a/Makefile b/Makefile
>> index d6f3695..68f0172 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1343,7 +1345,12 @@ all:: $(TEST_PROGRAMS)
>>
>> export NO_SVN_TESTS
>>
>> -test: all
>> +valgrind-setup: $(patsubst %.sh,%,$(VALGRIND_SH))
>> + rm -rf t/valgrind/bin
>> + mkdir t/valgrind/bin
>> + for i in git $(PROGRAMS); do cp test-valgrind t/valgrind/bin/$$i; done
>
> I wonder if it would not be better to scrap the t/valgrind/ directory and
> regenerate it everytime you run a test manually; I'd use "ln" instead of
> "cp", and also parse command-list.txt to catch really all of them (even if
> a dashed form is used for a builtin by mistake).
Going one step further, I wonder if this approach can also be used to
catch such a mistake. Install a dashed form that records the fact that it
was called when it shouldn't, and by whom.
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Stephen Rothwell @ 2008-10-22 23:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, linux-next,
Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810221908100.22125@pacific.mpi-cbg.de.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
Hi Johannes,
On Wed, 22 Oct 2008 19:41:18 +0200 (CEST) Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> I think it might be in order to explain how git-rerere works internally:
Thanks for the explanation.
> So I think that you might hit the unfortunate case where two files
> happened to have the same conflicts, but you needed to resolve them one
> way for one file, and another way for the other file.
Which makes perfect sense, unfortunately.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [OT] Amazon wishlist (was Re: [ANNOUCNE] repo - The Multiple Git Repository Tool)
From: Shawn O. Pearce @ 2008-10-22 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpxctcpk.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> By the way, are you still in need of a folding bookshelf from Target?
> >
> > If you saw my wife's book collection, and the space we have, you'd
> > understand my need for bookshelves... sadly we only have one.
> > Why do you ask?
>
> Because I stumbled across:
>
> http://www.amazon.com/gp/registry/registry.html?ie=UTF8&type=wishlist&id=1XF91IZ5VXGTQ
>
> recalled that you moved recently, thought perhaps it might be a good
> idea to send you a housewarming gift, but was not sure if this list really
> belonged to the person I thought.
Heh, that's very kind. Yes, it is actually my list, but I never use
it so I often forget I put things onto it. I think I actually use
it as a way to bookmark something I'm looking at on Amazon, and then
never wind up going back to because I just didn't get around to it.
Last year my thoughtful wife bought my birthday gift from my Amazon
wish list. It was a DVD set that I had wanted, but many months
before my birthday I had viewed the entire series through Netflix
and totally forgot it was on an Amazon wish list. She had no clue
and wound up purchasing the DVDs for me anyway. :)
> Crazy people claim to be somebody else while wishing for something the
> person they are disguising as never would. Once I looked for and found a
> Linus Torvalds who wanted a bunch of mysql+php books ;-)
Hah! Amazon is dangerous that way. Looking things up by name.
Email is usually slightly more unique...
--
Shawn.
^ permalink raw reply
* [OT] Amazon wishlist (was Re: [ANNOUCNE] repo - The Multiple Git Repository Tool)
From: Junio C Hamano @ 2008-10-22 23:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081022231756.GY14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> By the way, are you still in need of a folding bookshelf from Target?
>
> If you saw my wife's book collection, and the space we have, you'd
> understand my need for bookshelves... sadly we only have one.
> Why do you ask?
Because I stumbled across:
http://www.amazon.com/gp/registry/registry.html?ie=UTF8&type=wishlist&id=1XF91IZ5VXGTQ
recalled that you moved recently, thought perhaps it might be a good
idea to send you a housewarming gift, but was not sure if this list really
belonged to the person I thought.
Crazy people claim to be somebody else while wishing for something the
person they are disguising as never would. Once I looked for and found a
Linus Torvalds who wanted a bunch of mysql+php books ;-)
I was on Amazon's wishlist page because recently somebody asked me about
it, probably after reading http://gitster.livejournal.com/ (where I
mentioned I recently created one for myself without mentioning its URL --
the page has since been updated with one).
^ permalink raw reply
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Junio C Hamano @ 2008-10-22 23:21 UTC (permalink / raw)
To: Charles Bailey
Cc: git, Jeff King, William Pursell, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <20081022211720.GA23146@hashpling.org>
Charles Bailey <charles@hashpling.org> writes:
> I'm pretty keen on this patch, but have no strong opinions on which
> short option is used, so are there any votes against -y?
Between 'n' and 'y', I am in favour of the latter, but at the same time I
have to wonder if there are other commands that would want "Assume yes"
option. It could be that this single command that prompts for "Is this
Ok" is an oddball and giving it an "interactive" option to trigger the
current behaviour might make things more consistent. I dunno.
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 23:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdvkte4i.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> By the way, are you still in need of a folding bookshelf from Target?
If you saw my wife's book collection, and the space we have, you'd
understand my need for bookshelves... sadly we only have one.
Why do you ask?
--
Shawn.
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Junio C Hamano @ 2008-10-22 23:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081022211320.GW14786@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>> > Google developed two tools, repo and Gerrit, and open sourced them
>> > under the Apache License:
>> >
>> > http://android.git.kernel.org/?p=tools/repo.git
>> > http://android.git.kernel.org/?p=tools/gerrit.git
>> >
>> > git://android.git.kernel.org/tools/repo.git
>> > git://android.git.kernel.org/tools/gerrit.git
>>
>> Heh, very nice, with a very shallow history ;-)
>
> Yea, well, some of our history messages are downright messy and/or
> contain information we don't want to disclose to the public. Its
> apparently "normal" for Google to just drop history when it opens
> a code base. :-\
Yeah, I understand that would be a norm for anybody who wasn't originally
open. I was just teasing, not really complaining ;-)
By the way, are you still in need of a folding bookshelf from Target?
^ permalink raw reply
* Re: git performance
From: Jakub Narebski @ 2008-10-22 22:42 UTC (permalink / raw)
To: Edward Ned Harvey; +Cc: git
In-Reply-To: <000801c93483$2fdad340$8f9079c0$@com>
"Edward Ned Harvey" <git@nedharvey.com> writes:
> I see things all over the Internet saying git is fast. I'm
> currently struggling with poor svn performance and poor attitude of
> svn developers, so I'd like to consider switching to git. A quick
> question first.
>
> The core of the performance problem I'm facing is the need to "walk
> the tree" for many thousand files. Every time I do "svn update" or
> "svn status" the svn client must stat every file to check for local
> modifications (a coffee cup or a beer worth of stats). In essence,
> this is unavoidable if there is no mechanism to constantly monitor
> filesystem activity during normal operations. Analogous to
> filesystem journaling.
>
> So - I didn't see anything out there saying "git is fast because it
> uses inotify" or anything like that. Perhaps git would not help me
> at all? Because git still needs to stat all the files in the tree?
http://git.or.cz/gitwiki/GitBenchmarks
While it should be possible to use 'assume unchanged' bit together
with inotify / icron, it is not something tha is done; IIRC Mercurial
had Linux-only InotifyPlugin...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: Jakub Narebski @ 2008-10-22 22:40 UTC (permalink / raw)
To: Weiwei Shu; +Cc: git
In-Reply-To: <65d12cb10810221458j14ef0009u679cdb0f73299d7f@mail.gmail.com>
"Weiwei Shu" <shuww1980@gmail.com> writes:
> My first post in this mailing list. Could some one direct me to some
> document/manual pages to setup Git to treat ascii files as binary
> files? I'm using Git to do circuit schematics (SPICE files)
> versioning. I will not do any merging or editing stuff with external
> editors. The only way to change it is to use schematic capture GUIs
> (Cadence, ADS, etc). So I'd like to treat them as binary files to
> reduce the possibilities of messing them up.
>
> I know it seems a little bit stupid to use Git to do such an easy job.
> But hey, it's the most eye-catching SCM software, isn't it?
First, git does not modify files unless you have core.crlf set,
and even then it warns about irreversible transformations
(core.safecrlf)
Second, using gitattributes you can set diff driver and merge driver;
one of possibilities is to treat file as binary (binary diff and no
using 3-way file merge).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: Weiwei Shu @ 2008-10-22 22:35 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810221511590.24463@asgard.lang.hm>
Thanks David.
Well, for binary files, SCM tools (like subversion) usually work as
"lock-modify-unlock" mode in which merging is not supported since the
files are not human-readable. The schematics are ascii files, but I do
not want them to be merged if I run "merge" command. Instead I'd like
Git ask me to "look-and-replace". I know Git is not meant to do this
kind of jobs. Just curious if it is able to be configured to work in
that way.
On Wed, Oct 22, 2008 at 5:13 PM, <david@lang.hm> wrote:
> On Wed, 22 Oct 2008, Weiwei Shu wrote:
>
>> Hello everyone,
>>
>> My first post in this mailing list. Could some one direct me to some
>> document/manual pages to setup Git to treat ascii files as binary
>> files? I'm using Git to do circuit schematics (SPICE files)
>> versioning. I will not do any merging or editing stuff with external
>> editors. The only way to change it is to use schematic capture GUIs
>> (Cadence, ADS, etc). So I'd like to treat them as binary files to
>> reduce the possibilities of messing them up.
>>
>> I know it seems a little bit stupid to use Git to do such an easy job.
>> But hey, it's the most eye-catching SCM software, isn't it?
>
> unless you enable cr/lf handling git won't change ascii files.
>
> what is it that you think needs to be done differently for these files than
> for any other files?
>
> David Lang
>
--
Weiwei
--Hope Springs Eternal.
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: David Symonds @ 2008-10-22 22:13 UTC (permalink / raw)
To: Weiwei Shu; +Cc: git
In-Reply-To: <65d12cb10810221458j14ef0009u679cdb0f73299d7f@mail.gmail.com>
On Wed, Oct 22, 2008 at 2:58 PM, Weiwei Shu <shuww1980@gmail.com> wrote:
> My first post in this mailing list. Could some one direct me to some
> document/manual pages to setup Git to treat ascii files as binary
> files? I'm using Git to do circuit schematics (SPICE files)
> versioning. I will not do any merging or editing stuff with external
> editors. The only way to change it is to use schematic capture GUIs
> (Cadence, ADS, etc). So I'd like to treat them as binary files to
> reduce the possibilities of messing them up.
Git doesn't futz with your file contents unless you explicitly ask it
to, such as the CRLF-munging stuff. By default, all files are
"binary".
Dave.
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: david @ 2008-10-22 22:13 UTC (permalink / raw)
To: Weiwei Shu; +Cc: git
In-Reply-To: <65d12cb10810221458j14ef0009u679cdb0f73299d7f@mail.gmail.com>
On Wed, 22 Oct 2008, Weiwei Shu wrote:
> Hello everyone,
>
> My first post in this mailing list. Could some one direct me to some
> document/manual pages to setup Git to treat ascii files as binary
> files? I'm using Git to do circuit schematics (SPICE files)
> versioning. I will not do any merging or editing stuff with external
> editors. The only way to change it is to use schematic capture GUIs
> (Cadence, ADS, etc). So I'd like to treat them as binary files to
> reduce the possibilities of messing them up.
>
> I know it seems a little bit stupid to use Git to do such an easy job.
> But hey, it's the most eye-catching SCM software, isn't it?
unless you enable cr/lf handling git won't change ascii files.
what is it that you think needs to be done differently for these files
than for any other files?
David Lang
^ permalink raw reply
* Re: [RFC PATCH 1/5] add valgrind support in test scripts
From: Johannes Schindelin @ 2008-10-22 22:13 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081022202915.GA4547@coredump.intra.peff.net>
Hi,
On Wed, 22 Oct 2008, Jeff King wrote:
> diff --git a/Makefile b/Makefile
> index d6f3695..68f0172 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1343,7 +1345,12 @@ all:: $(TEST_PROGRAMS)
>
> export NO_SVN_TESTS
>
> -test: all
> +valgrind-setup: $(patsubst %.sh,%,$(VALGRIND_SH))
> + rm -rf t/valgrind/bin
> + mkdir t/valgrind/bin
> + for i in git $(PROGRAMS); do cp test-valgrind t/valgrind/bin/$$i; done
I wonder if it would not be better to scrap the t/valgrind/ directory and
regenerate it everytime you run a test manually; I'd use "ln" instead of
"cp", and also parse command-list.txt to catch really all of them (even if
a dashed form is used for a builtin by mistake).
Otherwise: good work, I like it!
Ciao,
Dscho
^ permalink raw reply
* how to configure Git to treat certain type of ascii files as binary files
From: Weiwei Shu @ 2008-10-22 21:58 UTC (permalink / raw)
To: git
Hello everyone,
My first post in this mailing list. Could some one direct me to some
document/manual pages to setup Git to treat ascii files as binary
files? I'm using Git to do circuit schematics (SPICE files)
versioning. I will not do any merging or editing stuff with external
editors. The only way to change it is to use schematic capture GUIs
(Cadence, ADS, etc). So I'd like to treat them as binary files to
reduce the possibilities of messing them up.
I know it seems a little bit stupid to use Git to do such an easy job.
But hey, it's the most eye-catching SCM software, isn't it?
--
Weiwei
--Hope Springs Eternal.
^ permalink raw reply
* RE: git performance
From: Edward Ned Harvey @ 2008-10-22 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <20081022203624.GA4585@coredump.intra.peff.net>
> Yes, it does stat all the files. How many files are you talking about,
> and what platform? From a warm cache on Linux, the 23,000 files kernel
> repo takes about a tenth of a second to stat all files for me (and this
> on a several year-old machine). And of course many operations don't
> require stat'ing at all (like looking at logs, or diffs that don't
> involve the working tree).
No worries. No solution can meet everyone's needs.
I'm talking about 40-50,000 files, on multi-user production linux, which means the cache is never warm, except when I'm benchmarking. Specifically RHEL 4 with the files on NFS mount. Cold cache "svn st" takes ~10 mins. Warm cache 20-30 sec. Surprisingly to me, performance was approx the same for files on local disk versus NFS. Probably the best solution for us is perforce, we just don't like the pricetag.
Out of curiosity, what are they talking about, when they say "git is fast?" Just the fact that it's all local disk, or is there more to it than that? I could see - git would probably outperform perforce for versioning of large files (let's say iso files) to benefit from sustained local disk IO, while perforce would probably outperform anything I can think of, operating on thousands of tiny files, because it will never walk the tree.
^ permalink raw reply
* [PATCH] Fixed git archive for bare repos
From: Charles Bailey @ 2008-10-22 21:47 UTC (permalink / raw)
To: git; +Cc: Deskin Miller, kenneth johansson, gitster
In-Reply-To: <20081022210913.GB22541@hashpling.org>
This moves the call to git config to a place where it doesn't break the
logic for using git archive in a bare repository but retains the fix to
make git archive respect core.autocrlf.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
OK, I've had a chance to have a quick look at this issue and I have an
altenative patch.
This is an alternative fix to the current git archive in a bare
repository issue.
It's been lightly tested and doesn't re-break the zip / autocrlf issue
that the previous introduction of git_config was designed to fix.
archive.c | 2 ++
builtin-archive.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/archive.c b/archive.c
index 849eed5..9ac455d 100644
--- a/archive.c
+++ b/archive.c
@@ -336,5 +336,7 @@ int write_archive(int argc, const char **argv, const char *prefix,
parse_treeish_arg(argv, &args, prefix);
parse_pathspec_arg(argv + 1, &args);
+ git_config(git_default_config, NULL);
+
return ar->write_archive(&args);
}
diff --git a/builtin-archive.c b/builtin-archive.c
index 432ce2a..5ceec43 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -111,8 +111,6 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
{
const char *remote = NULL;
- git_config(git_default_config, NULL);
-
remote = extract_remote_arg(&argc, argv);
if (remote)
return run_remote_archiver(remote, argc, argv);
--
1.6.0.2.534.g5ab59
^ permalink raw reply related
* Re: [PATCH 2/3] Add -n/--no-prompt option to mergetool
From: Charles Bailey @ 2008-10-22 21:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, William Pursell, Andreas Ericsson,
Theodore Ts'o
In-Reply-To: <20081021122655.GA29294@hashpling.org>
On Tue, Oct 21, 2008 at 01:26:55PM +0100, Charles Bailey wrote:
> On Tue, Oct 21, 2008 at 01:49:30PM +0200, Andreas Ericsson wrote:
> >
> > There is discussion already about "-n should be for dry-run!" and git's
> > inconsistencies in such matters. Wouldn't -y ("assume yes on prompt")
> > be better?
> >
>
> I must have missed this discussion. I've just had a very quick look at
> a handful of basic modifying git commands (merge, pull, commit,
> checkout, reset, revert) and only found 'add' that used -n as
> --dry-run.
>
> That said, I've no real objections to -y if that makes for a better
> consensus.
>
I'm pretty keen on this patch, but have no strong opinions on which
short option is used, so are there any votes against -y?
If I re-roll with the favoured short option is there anything else
that would prevent its adoption into next or master?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 21:16 UTC (permalink / raw)
To: Leo Razoumov; +Cc: git
In-Reply-To: <ee2a733e0810221255u23aabef2i66d878bcbfa11816@mail.gmail.com>
Leo Razoumov <slonik.az@gmail.com> wrote:
> On 10/22/08, Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > Google developed two tools, repo and Gerrit, and open sourced them
> > under the Apache License:
> >
> > http://android.git.kernel.org/?p=tools/repo.git
> > http://android.git.kernel.org/?p=tools/gerrit.git
> >
> > git://android.git.kernel.org/tools/repo.git
> > git://android.git.kernel.org/tools/gerrit.git
> >
> > repo is a Python application to bind together Git repositories,
> > something like "git submodule",
>
> Are there any plans to make repo an official git command (e.g.
> git-repo) or merge its functionality with git-submodule?
I currently do not plan on asking Junio to consider making repo part
of git. However, I am also not adverse to it if repo development
slows down and there is sufficient community interest.
--
Shawn.
^ permalink raw reply
* Re: git performance
From: Peter Harris @ 2008-10-22 21:13 UTC (permalink / raw)
To: Jeff King; +Cc: Edward Ned Harvey, git
In-Reply-To: <20081022203624.GA4585@coredump.intra.peff.net>
On Wed, Oct 22, 2008 at 4:36 PM, Jeff King wrote:
> On Wed, Oct 22, 2008 at 04:17:16PM -0400, Edward Ned Harvey wrote:
>
>> So - I didn't see anything out there saying "git is fast because it
>> uses inotify" or anything like that. Perhaps git would not help me at
>> all? Because git still needs to stat all the files in the tree?
>
> Yes, it does stat all the files. How many files are you talking about,
> and what platform? From a warm cache on Linux, the 23,000 files kernel
> repo takes about a tenth of a second to stat all files for me (and this
> on a several year-old machine). And of course many operations don't
> require stat'ing at all (like looking at logs, or diffs that don't
> involve the working tree).
Windows is rather slower than Linux, so differences are more obvious.
I find git feels "only" about 2x as fast as svn at status. svn has to
stat all of its base files too, whereas git has the index. git pull
(vs svn update) feels better than 2x faster, since git doesn't need to
walk the tree and lock every sub-dir before it even connects to the
remote server.
So we're not talking 'inotify' fast, but maybe half a cup of coffee
instead of a full cup if you have that many files.
"git-svn" is really quite good. I recommend you try a quick (trunk and
maybe one branch only, last few revisions only) import of your svn
tree to test with.
Peter Harris
^ permalink raw reply
* Re: [ANNOUCNE] repo - The Multiple Git Repository Tool
From: Shawn O. Pearce @ 2008-10-22 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlkwtpbq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Google developed two tools, repo and Gerrit, and open sourced them
> > under the Apache License:
> >
> > http://android.git.kernel.org/?p=tools/repo.git
> > http://android.git.kernel.org/?p=tools/gerrit.git
> >
> > git://android.git.kernel.org/tools/repo.git
> > git://android.git.kernel.org/tools/gerrit.git
>
> Heh, very nice, with a very shallow history ;-)
Yea, well, some of our history messages are downright messy and/or
contain information we don't want to disclose to the public. Its
apparently "normal" for Google to just drop history when it opens
a code base. :-\
The repo and Gerrit histories are short enough that I might
be able to go through them and clean them up some (remove any
comments revealing Google secrets) and publish the history under a
different repository. Folks can always graft it behind the (now)
real repository.
I can't promise anything, but I'll talk to my co-contributors and
consider doing this in the near future.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] archive: fix setup to work in bare repositories
From: Charles Bailey @ 2008-10-22 21:09 UTC (permalink / raw)
To: Deskin Miller; +Cc: kenneth johansson, git, gitster
In-Reply-To: <20081022203722.GD2015@riemann.deskinm.fdns.net>
On Wed, Oct 22, 2008 at 04:37:22PM -0400, Deskin Miller wrote:
> cmd_archive was calling git_config -> setup_git_env prior to
> write_archive calling setup_git_directory. In a bare repository, the
> former will set git_dir to be '.git' since the latter has not
> determined that it's operating in a bare repository yet.
>
> Things are complicated, however, by the fact that git archive --list
> should work from anywhere, not just in git repositories, so that
> argument needs to be checked for before setup_git_directory is called.
Just for some background, I think that this issue might be an
unintended consequence of this commit:
b99b5b40cffb5269e4aa38b6b60391b55039e27d
The only reason that the git_config call has been added is to ensure
the correct setting of core.autocrlf before convert_to_working_tree is
called on any blobs.
I haven't looked in detail, but would moving this call later make for
an cleaner change?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [RFC PATCH] archive: fix setup to work in bare repositories
From: Jeff King @ 2008-10-22 20:46 UTC (permalink / raw)
To: Deskin Miller; +Cc: kenneth johansson, git, gitster
In-Reply-To: <20081022203722.GD2015@riemann.deskinm.fdns.net>
On Wed, Oct 22, 2008 at 04:37:22PM -0400, Deskin Miller wrote:
> cmd_archive was calling git_config -> setup_git_env prior to
> write_archive calling setup_git_directory. In a bare repository, the
> former will set git_dir to be '.git' since the latter has not
> determined that it's operating in a bare repository yet.
>
> Things are complicated, however, by the fact that git archive --list
> should work from anywhere, not just in git repositories, so that
> argument needs to be checked for before setup_git_directory is called.
Should you perhaps be able to call setup_git_directory_gently(), and
then once you decide that you really do need the setup, call
setup_git_directory()?
You would have to add a "did we already do run" flag to
setup_git_directory_gently(), but I think it is already an error to call
it twice, so you wouldn't be hurting anything by that.
Note also that by moving the setup, you are moving the chdir() that
happens; you may need to prefix paths to any arguments to accomodate
this (I don't think it should matter, since git-archive shouldn't look
at any paths until after it would have done the setup_git_directory()
before, but I didn't check carefully).
-Peff
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 20:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gdo1a3$akl$1@ger.gmane.org>
On Wed, Oct 22, 2008 at 10:12:54PM +0200, Jakub Narebski wrote:
> Currently you can use path_info URL for blob_plain
>
> http://repo.or.cz/w/git/gitbuild.git/platform:/jk/solaris/config.mak
Ah, I didn't know that. Thanks.
> Soon (thanks to Giuseppe patches) you would be able to use
>
> http://repo.or.cz/w/git/gitbuild.git/blob/platform:/jk/solaris/config.mak
Yes, those patches were actually what spurred my comment. :) I am
looking forward to playing with them once they are on repo.or.cz.
-Peff
^ 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