* 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
* 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: [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
* 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: 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: 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: 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: 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: [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: [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: [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
* [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: [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
* 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: [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: [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
* [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: [RFC PATCH 4/5] pack-objects: avoid reading uninitalized data
From: Nicolas Pitre @ 2008-10-23 1:11 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081022203103.GD4547@coredump.intra.peff.net>
On Wed, 22 Oct 2008, Jeff King wrote:
> In the main loop of find_deltas, we do:
>
> struct object_entry *entry = *list++;
> ...
> if (!*list_size)
> ...
> break
>
> Because we look at and increment *list _before_ the check of
> list_size, in the very last iteration of the loop we will
> look at uninitialized data, and increment the pointer beyond
> one past the end of the allocated space. Since we don't
> actually do anything with the data until after the check,
> this is not a problem in practice.
>
> But since it technically violates the C standard, and
> because it provokes a spurious valgrind warning, let's just
> move the initialization of entry to a safe place.
>
> This fixes valgrind errors in t5300, t5301, t5302, t303, and
> t9400.
>
> Signed-off-by: Jeff King <peff@peff.net>
OK. Minor nit...
> ---
> builtin-pack-objects.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
> index 59c30d1..15b80db 100644
> --- a/builtin-pack-objects.c
> +++ b/builtin-pack-objects.c
> @@ -1375,7 +1375,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
> array = xcalloc(window, sizeof(struct unpacked));
>
> for (;;) {
> - struct object_entry *entry = *list++;
> + struct object_entry *entry;
> struct unpacked *n = array + idx;
> int j, max_depth, best_base = -1;
>
> @@ -1384,6 +1384,7 @@ static void find_deltas(struct object_entry **list, unsigned *list_size,
> progress_unlock();
> break;
> }
---> Please preserve the empty line here so the previous code
chunk still appears logically separate.
> + entry = *list++;
> (*list_size)--;
> if (!entry->preferred_base) {
> (*processed)++;
Nicolas
^ permalink raw reply
* Re: how to configure Git to treat certain type of ascii files as binary files
From: Weiwei Shu @ 2008-10-23 1:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3hc74i73a.fsf@localhost.localdomain>
Thanks Jakub. I'll read its manual and try to play with it. Thank all
for replies!
On Wed, Oct 22, 2008 at 5:40 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "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
>
--
Weiwei
--Hope Springs Eternal.
^ permalink raw reply
* [PATCH] Implement git remote mv
From: Miklos Vajna @ 2008-10-23 1:18 UTC (permalink / raw)
To: Brandon Casey; +Cc: Junio C Hamano, git
In-Reply-To: <JQScKsOjmj-C7kmMPApAxZ3UDmaTZ1j0HkObQuCveJ9n4G-4o6Zxbw@cipher.nrlssc.navy.mil>
The new rename subcommand does the followings:
1) Renames the remote.foo configuration section to remote.bar
2) Updates the remote.bar.fetch refspecs
3) Updates the branch.*.remote settings
4) Renames the tracking branches.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Wed, Oct 22, 2008 at 11:52:54AM -0500, Brandon Casey <casey@nrlssc.navy.mil> wrote:
> > + struct rename_info rename = { argv[1], argv[2], &remote_branches
> > };
>
> I think some non-c99 compilers would have issues with this run-time
> initialization from function arguments. Plus, what if argv doesn't
> have
> 3 elements? I see you have a check for that below...
Hm true. Here is a corrected version.
Documentation/git-remote.txt | 6 ++
builtin-remote.c | 106 ++++++++++++++++++++++++++++++++++++++++++
t/t5505-remote.sh | 14 ++++++
3 files changed, 126 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index bb99810..4b5542a 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git remote' [-v | --verbose]
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+'git remote mv' <old> <new>
'git remote rm' <name>
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
@@ -61,6 +62,11 @@ only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, `git push` will always behave as if `\--mirror`
was passed.
+'mv'::
+
+Rename the remote named <old> to <new>. All remote tracking branches and
+configuration settings for the remote are updated.
+
'rm'::
Remove the remote named <name>. All remote tracking branches and
diff --git a/builtin-remote.c b/builtin-remote.c
index 6b3325d..8a54bca 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -10,6 +10,7 @@
static const char * const builtin_remote_usage[] = {
"git remote",
"git remote add <name> <url>",
+ "git remote mv <old> <new>",
"git remote rm <name>",
"git remote show <name>",
"git remote prune <name>",
@@ -329,6 +330,109 @@ static int add_branch_for_removal(const char *refname,
return 0;
}
+struct rename_info {
+ const char *old;
+ const char *new;
+ struct string_list *remote_branches;
+};
+
+static int read_remote_branches(const char *refname,
+ const unsigned char *sha1, int flags, void *cb_data)
+{
+ struct rename_info *rename = cb_data;
+ struct strbuf buf = STRBUF_INIT;
+
+ strbuf_addf(&buf, "refs/remotes/%s", rename->old);
+ if(!prefixcmp(refname, buf.buf))
+ string_list_append(xstrdup(refname), rename->remote_branches);
+
+ return 0;
+}
+
+static int mv(int argc, const char **argv)
+{
+ struct option options[] = {
+ OPT_END()
+ };
+ struct remote *oldremote, *newremote;
+ struct strbuf buf = STRBUF_INIT, buf2 = STRBUF_INIT;
+ struct string_list remote_branches = { NULL, 0, 0, 0 };
+ struct rename_info rename;
+ int i;
+
+ if (argc != 3)
+ usage_with_options(builtin_remote_usage, options);
+
+ rename.old = argv[1];
+ rename.new = argv[2];
+ rename.remote_branches = &remote_branches;
+
+ oldremote = remote_get(rename.old);
+ if (!oldremote)
+ die("No such remote: %s", rename.old);
+
+ newremote = remote_get(rename.new);
+ if (newremote && (newremote->url_nr > 1 || newremote->fetch_refspec_nr))
+ die("remote %s already exists.", rename.new);
+
+ strbuf_addf(&buf, "refs/heads/test:refs/remotes/%s/test", rename.new);
+ if (!valid_fetch_refspec(buf.buf))
+ die("'%s' is not a valid remote name", rename.new);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s", rename.old);
+ strbuf_addf(&buf2, "remote.%s", rename.new);
+ if (git_config_rename_section(buf.buf, buf2.buf) < 1)
+ return error("Could not rename config section '%s' to '%s'",
+ buf.buf, buf2.buf);
+
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "remote.%s.fetch", rename.new);
+ if (git_config_set_multivar(buf.buf, NULL, NULL, 1))
+ return error("Could not remove config section '%s'", buf.buf);
+ for (i = 0; i < oldremote->fetch_refspec_nr; i++) {
+ char *ptr;
+
+ strbuf_reset(&buf2);
+ strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
+ ptr = strstr(buf2.buf, rename.old);
+ if (ptr)
+ strbuf_splice(&buf2, ptr-buf2.buf, strlen(rename.old),
+ rename.new, strlen(rename.new));
+ if (git_config_set_multivar(buf.buf, buf2.buf, "^$", 0))
+ return error("Could not append '%s'", buf.buf);
+ }
+
+ read_branches();
+ for (i = 0; i < branch_list.nr; i++) {
+ struct string_list_item *item = branch_list.items + i;
+ struct branch_info *info = item->util;
+ if (info->remote && !strcmp(info->remote, rename.old)) {
+ strbuf_reset(&buf);
+ strbuf_addf(&buf, "branch.%s.remote", item->string);
+ if (git_config_set(buf.buf, rename.new)) {
+ return error("Could not set '%s'", buf.buf);
+ }
+ }
+ }
+
+ for_each_ref(read_remote_branches, &rename);
+ for (i = 0; i < remote_branches.nr; i++) {
+ struct string_list_item *item = remote_branches.items + i;
+ strbuf_reset(&buf);
+ strbuf_addstr(&buf, item->string);
+ strbuf_splice(&buf, strlen("refs/remotes/"), strlen(rename.old),
+ rename.new, strlen(rename.new));
+ strbuf_reset(&buf2);
+ strbuf_addf(&buf2, "remote: renamed %s to %s",
+ item->string, buf.buf);
+ if (rename_ref(item->string, buf.buf, buf2.buf))
+ die("renaming '%s' failed", item->string);
+ }
+
+ return 0;
+}
+
static int remove_branches(struct string_list *branches)
{
int i, result = 0;
@@ -696,6 +800,8 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show_all();
else if (!strcmp(argv[0], "add"))
result = add(argc, argv);
+ else if (!strcmp(argv[0], "mv"))
+ result = mv(argc, argv);
else if (!strcmp(argv[0], "rm"))
result = rm(argc, argv);
else if (!strcmp(argv[0], "show"))
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index c449663..9b11fd3 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -324,4 +324,18 @@ test_expect_success 'reject adding remote with an invalid name' '
'
+# The first three tests if the config is properly updated, the last one
+# checks if the branches are renamed.
+
+test_expect_success 'rename a remote' '
+
+ git clone one four &&
+ (cd four &&
+ git remote mv origin upstream &&
+ git remote show |grep -q upstream &&
+ git config remote.upstream.fetch |grep -q upstream &&
+ test $(git config branch.master.remote) = "upstream" &&
+ git for-each-ref|grep -q refs/remotes/upstream)
+
+'
test_done
--
1.6.0.2
^ permalink raw reply related
* Tip: avoiding net overhead using git over sshfs
From: Felipe Carvalho Oliveira @ 2008-10-23 1:26 UTC (permalink / raw)
To: git
Use git over sshfs is not so good, but is an option for people that
don't have shell acess to the server/hosting like me.
# mounting
sshfs -o workaround=rename <user>@<host>:/home/<user>/ <mount_point>
cd <the_directory_of_your_project>
# we will move the .git directory to the local filesystem
mv .git ~/.my_project_git
# and create a symlink to the local .git
ln -s ~/.my_project_git .git
Done!
Now you can open gitk instantly ;-) and don't need to have the entire
.git thing on a remote filesystem.
Felipe (from Brazil, my english skills aren't so good :-)
^ permalink raw reply
* [RFC] Zit: the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-23 1:29 UTC (permalink / raw)
To: git
Hello all,
one of the common remarks done about git is that since it tracks
tree contents, it's not the best-suited tool to track a bunch of
independent files which happen to be in the same directory.
I've found myself in the situation of wanting to track my changes done
to one or more 'single' files in a directory (e.g. $HOME), and
deciding to use antiquate, clumsy, slow and inefficient but file-based
RCS (yes, you read that right) over git.
In other situations (e.g. for my UserJS folder) I ended up using git,
but not liking the idea of having things such as tags referring to all
of my UserJS projects instead of the single file they were inteded
for, or having to put 'filename: ' at the beginning of commit messages
just because the history was shared.
So today I decided to start hacking at a git-based but file-oriented
content tracker, which I decided to name Zit.
The principle is extremely simple: when you choose to start tracking a
file with Zit,
zit track file
Zit will create a directory .zit.file to hold a git repository
tracking the single file .zit.file/file, which is just a hard link to
file.
The reason for using .zit.file as a non-bare repository rather than
just a GIT_DIR is that it allows things such as 'git status' to ignore
everything else. A possible alternative could have been to use
.zit.file as the GIT_DIR and create an all-encopassing
.zit.file/info/exclude, but the general idea of having this kind of
detached GIT_DIR felt less robust (or maybe I just forgot some
export).
I also don't like the idea of the hardlink, first of all because of
portability problems, and secondly because of the way too many
possibility that the hardlink broke somewhere along the way. For
example, I haven't tested any fancy git commands on my sample zit
implementation, and I'm not sure checking out some older version would
actually work.
If anybody is intered in trying out my quick hack for the idea,
there's a git repository for Zit at git://git.oblomov.eu/zit --beware
that nothing past the most elementary uses (i.e. diff, status, log,
commit) has been tested yet. Many commands are bound to fail due to
the braindead way commands are delegated to git.
Suggestions on the best way to approach the many limits of the
implementation are more than welcome.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] Fixed git archive for bare repos
From: Deskin Miller @ 2008-10-23 1:37 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, kenneth johansson, gitster
In-Reply-To: <1224712023-5280-1-git-send-email-charles@hashpling.org>
On Wed, Oct 22, 2008 at 10:47:03PM +0100, Charles Bailey wrote:
> OK, I've had a chance to have a quick look at this issue and I have an
> altenative patch.
Thanks for making this much simpler than my version was; it passes the testcase
I wrote, as well as the rest of the testsuite, so if you want to include my
testcase (or an equivalent one) and re-send, consider it
Tested-by: Deskin Miller <deskinm@umich.edu>
^ permalink raw reply
* Re: [PATCH] Implement git remote mv
From: Jeff King @ 2008-10-23 3:52 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Brandon Casey, Junio C Hamano, git
In-Reply-To: <1224724704-12700-1-git-send-email-vmiklos@frugalware.org>
On Thu, Oct 23, 2008 at 03:18:24AM +0200, Miklos Vajna wrote:
> The new rename subcommand does the followings:
>
> 1) Renames the remote.foo configuration section to remote.bar
>
> 2) Updates the remote.bar.fetch refspecs
>
> 3) Updates the branch.*.remote settings
>
> 4) Renames the tracking branches.
I can't help but notice that the word "rename" appears all over the
commit description and in the code, but not in the user interface. Maybe
"rename" would be a better name for the command instead of (or in
addition to) "mv"?
-Peff
^ permalink raw reply
* What's cooking in git.git (Oct 2008, #05; Wed, 22)
From: Junio C Hamano @ 2008-10-23 5:41 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* cj/maint-gitpm-fix-maybe-self (Sat Oct 18 20:25:12 2008 +0200) 1 commit
+ Git.pm: do not break inheritance
Looked Ok; will be in 'master' soon.
* gb/gitweb-pathinfo (Tue Oct 21 21:34:54 2008 +0200) 5 commits
- gitweb: generate parent..current URLs
- gitweb: parse parent..current syntax from PATH_INFO
- gitweb: use_pathinfo filenames start with /
- gitweb: generate project/action/hash URLs
- gitweb: parse project/action/hash_base:filename PATH_INFO
Seventh iteration; hopefully the usual gitweb gangs will give quick
comments and ack to push this out to 'next' soon.
* ag/blame-encoding (Wed Oct 22 00:55:57 2008 +0400) 1 commit
+ builtin-blame: Reencode commit messages according to git-log
rules.
Looked Ok; will be in 'master' soon.
* mv/parseopt-checkout-index (Sat Oct 18 03:17:23 2008 +0200) 1 commit
+ parse-opt: migrate builtin-checkout-index.
Looked Ok; will be in 'master' soon.
----------------------------------------------------------------
[Graduated to "master"]
* rs/alloc-ref (Sat Oct 18 10:44:18 2008 +0200) 3 commits
+ make alloc_ref_from_str() the new alloc_ref()
+ use alloc_ref_from_str() everywhere
+ add alloc_ref_with_prefix()
* jc/maint-reset-remove-unmerged-new (Wed Oct 15 16:00:06 2008 -0700) 1 commit
+ reset --hard/read-tree --reset -u: remove unmerged new paths
Teaches "reset --hard" to remove new paths in conflict.
* jk/fix-ls-files-other (Fri Oct 17 13:03:52 2008 -0700) 2 commits
+ Merge branch 'jk/maint-ls-files-other' into jk/fix-ls-files-other
+ refactor handling of "other" files in ls-files and status
* jc/maint-co-track (Fri Oct 17 15:44:39 2008 -0700) 4 commits
+ Fix checkout not to clobber the branch when using symlinked HEAD
upon detaching
+ Enhance hold_lock_file_for_{update,append}() API
+ demonstrate breakage of detached checkout with symbolic link HEAD
+ Fix "checkout --track -b newbranch" on detached HEAD
* jk/maint-ls-files-other (Thu Oct 16 11:07:26 2008 -0400) 1 commit
+ refactor handling of "other" files in ls-files and status
* pb/commit-where (Fri Oct 3 22:13:49 2008 -0400) 4 commits
+ tutorial: update output of git commit
+ reformat informational commit message
+ git commit: Reformat output somewhat
+ builtin-commit.c: show on which branch a commit was added
* js/maint-fetch-update-head (Tue Oct 14 15:32:20 2008 -0700) 2 commits
+ pull: allow "git pull origin $something:$current_branch" into an
unborn branch
+ Fix fetch/pull when run without --update-head-ok
* ns/rebase-noverify (Tue Oct 14 08:17:16 2008 +0900) 2 commits
+ rebase: Document --no-verify option to bypass pre-rebase hook
+ rebase --no-verify
This adds --no-verify to git rebase, to avoid the pre-rebase hook.
* mv/merge-noff (Fri Oct 3 14:04:47 2008 +0200) 1 commit
+ builtin-commit: use reduce_heads() only when appropriate
Fixes "git merge --no-ff --no-commit".
* ae/preservemerge (Mon Sep 29 22:28:57 2008 +0200) 1 commit
+ rebase: Support preserving merges in non-interactive mode
* pb/rename-rowin32 (Fri Oct 3 12:20:43 2008 +0200) 1 commit
+ Do not rename read-only files during a push
Fixes pack file renames on Windows.
* sp/describe-lwtag (Mon Oct 13 07:39:46 2008 -0700) 1 commit
+ describe: Make --tags and --all match lightweight tags more often
When the user gives --tags, the request is asking to treat lightweight and
annotated tags at equal weight, and if lightweight ones are closer, they
should be used.
* gb/formatpatch-autonbr (Thu Oct 2 16:55:39 2008 -0400) 1 commit
+ format-patch: autonumber by default
* dp/checkattr (Wed Oct 15 09:11:52 2008 +0200) 3 commits
+ git-check-attr(1): use 'verse' for multi-line synopsis sections
+ check-attr: Add --stdin option
+ check-attr: add an internal check_attr() function
Batch attr lookup via --stdin, for gitk and git-gui.
* gb/refactor-pathinfo (Fri Oct 10 20:42:26 2008 +0200) 1 commit
+ gitweb: refactor input parameters parse/validation
A major cleanup on the way gitweb parses its input arguments.
Future gitweb patches to add more arguments into the PATH_INFO
depend upon this initial cleanup work.
* ml/cygwin-filemode (Mon Oct 13 00:33:31 2008 -0400) 1 commit
+ compat/cygwin.c - Use cygwin's stat if core.filemode == true
* mv/clonev (Thu Oct 9 01:40:32 2008 +0200) 1 commit
+ Implement git clone -v
Does what it says it does. This may be ready for master soon,
its a pretty trivial change.
* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits
+ Documentation: Refer to git-rebase(1) to warn against rewriting
+ Documentation: new upstream rebase recovery section in git-rebase
Also the workflow document itself is now in 'master'.
* sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
+ rebase--interactive: fix parent rewriting for dropped commits
* jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
+ diff: add filter for converting binary to text
+ diff: introduce diff.<driver>.binary
+ diff: unify external diff and funcname parsing code
+ t4012: use test_cmp instead of cmp
A general cleanup on how diff drivers are implemented. Its still
missing documentation updates and tests but doesn't break anything
current as far as I can tell.
----------------------------------------------------------------
[Stalled]
* nd/narrow (Wed Oct 1 11:04:09 2008 +0700) 9 commits
- grep: skip files outside sparse checkout area
- checkout_entry(): CE_NO_CHECKOUT on checked out entries.
- Prevent diff machinery from examining worktree outside sparse
checkout
- ls-files: Add tests for --sparse and friends
- update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
- update-index: refactor mark_valid() in preparation for new options
- ls-files: add options to support sparse checkout
- Introduce CE_NO_CHECKOUT bit
- Extend index to save more flags
Needs review.
* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits
- Use xdiff caching to improve git blame performance
- Allow xdiff machinery to cache hash results for a file
- Always initialize xpparam_t to 0
- Bypass textual patch generation and parsing in git blame
- Allow alternate "low-level" emit function from xdl_diff
Réne had good comments on how the callback should be structured.
Waiting for a reroll.
* jn/gitweb-customlinks (Sun Oct 12 00:02:32 2008 +0200) 1 commit
- gitweb: Better processing format string in custom links in navbar
Waiting for some sort of response from Pasky.
* jc/gitweb-fix-cloud-tag (Tue Oct 14 21:27:12 2008 -0700) 1 commit
+ Fix reading of cloud tags
Request-for-review-and-ack sent; waiting for response.
----------------------------------------------------------------
[Actively Cooking]
* np/index-pack (Wed Oct 22 20:59:22 2008 -0400) 4 commits
- improve index-pack tests
+ fix multiple issues in index-pack
+ index-pack: smarter memory usage during delta resolution
+ index-pack: rationalize delta resolution code
The buglets that caused people on 'next' some surprises are quickly
killed. Thanks.
* sh/rebase-i-p (Wed Oct 22 11:59:30 2008 -0700) 9 commits
+ git-rebase--interactive.sh: comparision with == is bashism
+ rebase-i-p: minimum fix to obvious issues
+ rebase-i-p: if todo was reordered use HEAD as the rewritten parent
+ rebase-i-p: do not include non-first-parent commits touching
UPSTREAM
+ rebase-i-p: only list commits that require rewriting in todo
+ rebase-i-p: fix 'no squashing merges' tripping up non-merges
+ rebase-i-p: delay saving current-commit to REWRITTEN if squashing
+ rebase-i-p: use HEAD for updating the ref instead of mapping
OLDHEAD
+ rebase-i-p: test to exclude commits from todo based on its parents
Changes the `rebase -i -p` behavior to behave like git sequencer's
rewrite of `rebase -i` would behave.
----------------------------------------------------------------
[On Hold]
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
- revision --simplify-merges: incremental simplification
- revision --simplify-merges: prepare for incremental simplification
I started making this incremental but the progress is not
so great.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
- blame: show "previous" information in --porcelain/--incremental
format
- git-blame: refactor code to emit "porcelain format" output
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
^ 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