* Re: is gitosis secure?
From: Nix @ 2008-12-13 16:23 UTC (permalink / raw)
To: sverre; +Cc: Thomas Koch, Git Mailing List, dabe
In-Reply-To: <bd6139dc0812090138l5dbaf20bsd1cde00f52bb94e5@mail.gmail.com>
On 9 Dec 2008, Sverre Rabbelier spake thusly:
> On Tue, Dec 9, 2008 at 09:56, Thomas Koch <thomas@koch.ro> wrote:
>> Our admin would prefer to not open SSH at all outside our LAN, but
>> developers would need to have write access also outside the office.
>
> What safer to connect to the LAN than with SSH? What _would_ your
> system admin be happy with using?
telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.
(Telnet over some horrible impossibly slow buggy proprietary VPN.
It takes >5min to bring up a single connection.)
Do not underestimate the stupidity and hideboundedness of undertrained
system administrators, for it is vast.
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Jean-Luc Herren @ 2008-12-13 16:44 UTC (permalink / raw)
To: git; +Cc: Resul Cetin, Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <200812131714.05472.Resul-Cetin@gmx.net>
Resul Cetin wrote:
> That would be a workaround but it doesn't explain why git.kernel.org deliveres
> torvalds repository without any notable counting and compressing time.
If I remember right, git.kernel.org is a quite beefy machine. But
then again it has a lot more traffic too. It might be interesting
to know what machine you're on, compared to git.kernel.org.
jlh
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Resul Cetin @ 2008-12-13 16:14 UTC (permalink / raw)
To: git; +Cc: Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <fcaeb9bf0812130746l38a12f37wde26f31d5fa0d2a2@mail.gmail.com>
On Saturday 13 December 2008 16:46:50 you wrote:
[...]
> > The size of the linux repository seems to be smaller but in the same
> > range object count and repository size but clones are much much faster.
> > Is there any way to optimize the server operations like counting and
> > compressing of objects to get the same speed as we get from
> > git.kernel.org (which does it in nearly no time and the only limiting
> > factor seems to be my bandwith)?
> > The only other information I have is that Robin H. Johnson made a single
> > ~910MiB pack for the whole repository.
>
> Make yearly packed repository snapshots and publish them via http.
> People can wget the latest snapshot, then pull updates later.
That would be a workaround but it doesn't explain why git.kernel.org deliveres
torvalds repository without any notable counting and compressing time. Maybe
it has something todo with the config I found inside the repository:
http://git.overlays.gentoo.org/gitroot/exp/gentoo-x86.git/config
It says that it isnt a bare repository.
Before I forget. I was wrong that it is a single 910mb file. Somebody seems to
have repacked it into 7 single packs.
Regards,
Resul
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Nguyen Thai Ngoc Duy @ 2008-12-13 15:46 UTC (permalink / raw)
To: Resul Cetin; +Cc: git, gentoo-scm
In-Reply-To: <200812131624.57618.Resul-Cetin@gmx.net>
On 12/13/08, Resul Cetin <Resul-Cetin@gmx.net> wrote:
> Hi,
> there are currently different ideas to move gentoo's cvs repository to an
> other scm. Current tests showed that svn will not make anything better (it
> gets in most perfomance and size based benchmarks even worse). Another idea is
> to move to git. It looks really promising in size based benchmarks but cloning
> seems nearly impossible. The current test repository is available at
> git://git.overlays.gentoo.org/exp/gentoo-x86.git and is around 900MB in size
> and has 4696137 objects. It really takes ages to do the counting of the
> objects on the server and compressing takes much longer.
> The size of the linux repository seems to be smaller but in the same range
> object count and repository size but clones are much much faster. Is there any
> way to optimize the server operations like counting and compressing of objects
> to get the same speed as we get from git.kernel.org (which does it in nearly
> no time and the only limiting factor seems to be my bandwith)?
> The only other information I have is that Robin H. Johnson made a single
> ~910MiB pack for the whole repository.
Make yearly packed repository snapshots and publish them via http.
People can wget the latest snapshot, then pull updates later.
--
Duy
^ permalink raw reply
* Optimizing cloning of a high object count repository
From: Resul Cetin @ 2008-12-13 15:24 UTC (permalink / raw)
To: git; +Cc: gentoo-scm
Hi,
there are currently different ideas to move gentoo's cvs repository to an
other scm. Current tests showed that svn will not make anything better (it
gets in most perfomance and size based benchmarks even worse). Another idea is
to move to git. It looks really promising in size based benchmarks but cloning
seems nearly impossible. The current test repository is available at
git://git.overlays.gentoo.org/exp/gentoo-x86.git and is around 900MB in size
and has 4696137 objects. It really takes ages to do the counting of the
objects on the server and compressing takes much longer.
The size of the linux repository seems to be smaller but in the same range
object count and repository size but clones are much much faster. Is there any
way to optimize the server operations like counting and compressing of objects
to get the same speed as we get from git.kernel.org (which does it in nearly
no time and the only limiting factor seems to be my bandwith)?
The only other information I have is that Robin H. Johnson made a single
~910MiB pack for the whole repository.
Thx in advance,
Resul
^ permalink raw reply
* Re: Announce: TortoiseGit 0.1 preview version
From: Tim Visher @ 2008-12-13 14:21 UTC (permalink / raw)
To: 李智; +Cc: git
In-Reply-To: <1976ea660812130033m2d54cc57tfe134fab0d687d71@mail.gmail.com>
On Sat, Dec 13, 2008 at 3:33 AM, 李智 <lznuaa@gmail.com> wrote:
> TortoiseGit is porting from TortoiseSVN.
Thanks so much for this!
My team and I were just talking about how the biggest barrier to entry
at this point for _some_ of us has been the lack of a great tool like
Tortoise for Git. My opinion was that someone would soon write it.
And lo-and-behold, here it is!
I'll look forward to watching this progress, and continue happily
using my cli version the same.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] autodetect number of CPUs by default when using threads
From: Jeff King @ 2008-12-13 13:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0812111524370.14328@xanadu.home>
On Thu, Dec 11, 2008 at 03:36:47PM -0500, Nicolas Pitre wrote:
> ... and display the actual number of threads used when locally
> repacking. A remote server still won't tell you how many threads it
> uses during a fetch though.
Hrm. I have no idea how, but this patch reliably causes t5300 to fail on
my FreeBSD test box ("next" is broken, bisection pointed to 43cc2b42).
Sample verbose output is below.
-- >8 --
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* expecting success: rm -f .git/index*
for i in a b c
do
dd if=/dev/zero bs=4k count=1 | perl -pe "y/\\000/$i/" >$i &&
git update-index --add $i || return 1
done &&
cat c >d && echo foo >>d && git update-index --add d &&
tree=`git write-tree` &&
commit=`git commit-tree $tree </dev/null` && {
echo $tree &&
echo $commit &&
git ls-tree $tree | sed -e "s/.* \\([0-9a-f]*\\) .*/\\1/"
} >obj-list && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >expect
1+0 records in
1+0 records out
4096 bytes transferred in 0.000059 secs (69273666 bytes/sec)
1+0 records in
1+0 records out
4096 bytes transferred in 0.000053 secs (77386798 bytes/sec)
1+0 records in
1+0 records out
4096 bytes transferred in 0.000055 secs (74695083 bytes/sec)
* ok 1: setup
* expecting success: packname_1=$(git pack-objects --window=0 test-1 <obj-list)
* ok 2: pack without delta
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
git unpack-objects -n <test-1-20f53d0edce6980dfa341c034ae365aef2616e8d.pack &&
git unpack-objects <test-1-20f53d0edce6980dfa341c034ae365aef2616e8d.pack
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 3: unpack without delta
* expecting success: (cd ../.git && find objects -type f -print) |
while read path
do
cmp $path ../.git/$path || {
echo $path differs.
return 1
}
done
* ok 4: check unpack without delta
* expecting success: pwd &&
packname_2=$(git pack-objects test-2 <obj-list)
/home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object
* ok 5: pack with REF_DELTA
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
git unpack-objects -n <test-2-${packname_2}.pack &&
git unpack-objects <test-2-${packname_2}.pack
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 6: unpack with REF_DELTA
* expecting success: (cd ../.git && find objects -type f -print) |
while read path
do
cmp $path ../.git/$path || {
echo $path differs.
return 1
}
done
* ok 7: check unpack with REF_DELTA
* expecting success: pwd &&
packname_3=$(git pack-objects --delta-base-offset test-3 <obj-list)
/home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object
* ok 8: pack with OFS_DELTA
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
git unpack-objects -n <test-3-${packname_3}.pack &&
git unpack-objects <test-3-${packname_3}.pack
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 9: unpack with OFS_DELTA
* expecting success: (cd ../.git && find objects -type f -print) |
while read path
do
cmp $path ../.git/$path || {
echo $path differs.
return 1
}
done
* ok 10: check unpack with OFS_DELTA
* expecting success:
perl -e '
defined($_ = -s $_) or die for @ARGV;
exit 1 if $ARGV[0] <= $ARGV[1];
' test-2-$packname_2.pack test-3-$packname_3.pack
* FAIL 11: compare delta flavors
perl -e '
defined($_ = -s $_) or die for @ARGV;
exit 1 if $ARGV[0] <= $ARGV[1];
' test-2-$packname_2.pack test-3-$packname_3.pack
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git init &&
cp test-1-${packname_1}.pack test-1-${packname_1}.idx .git2/objects/pack && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >current &&
diff expect current
Reinitialized existing Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/.git/
* ok 12: use packed objects
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
rm -f .git2/objects/pack/test-* &&
cp test-2-${packname_2}.pack test-2-${packname_2}.idx .git2/objects/pack && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >current &&
diff expect current
* ok 13: use packed deltified (REF_DELTA) objects
* expecting success: GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
rm -f .git2/objects/pack/test-* &&
cp test-3-${packname_3}.pack test-3-${packname_3}.idx .git2/objects/pack && {
git diff-tree --root -p $commit &&
while read object
do
t=`git cat-file -t $object` &&
git cat-file $t $object || return 1
done <obj-list
} >current &&
diff expect current
* ok 14: use packed deltified (OFS_DELTA) objects
* expecting success: git verify-pack test-1-${packname_1}.idx \
test-2-${packname_2}.idx \
test-3-${packname_3}.idx
* ok 15: verify pack
* expecting success: git verify-pack -v test-1-${packname_1}.idx \
test-2-${packname_2}.idx \
test-3-${packname_3}.idx
0be779221aca65277fd447c8207e1b3c2706ae20 blob 4096 31 311
2f22df7b2a002e7e84bd7c124483f0df7f7bc1ef commit 163 121 128
890b180ae96f7abd6a1917dee506bceb188003b6 tree 116 116 12
9d235ed07cd19811a6ceb342de82f190e49c9f68 blob 4096 31 249
b010fe5253f7dc59c6605dacb92fcea00d199d4e blob 4100 36 342
c82de19312b6c3695c0c18f70709a6c535682a67 blob 4096 31 280
test-1-20f53d0edce6980dfa341c034ae365aef2616e8d.pack: ok
0be779221aca65277fd447c8207e1b3c2706ae20 blob 4096 31 311
2f22df7b2a002e7e84bd7c124483f0df7f7bc1ef commit 163 121 128
890b180ae96f7abd6a1917dee506bceb188003b6 tree 116 116 12
9d235ed07cd19811a6ceb342de82f190e49c9f68 blob 4096 31 249
b010fe5253f7dc59c6605dacb92fcea00d199d4e blob 4100 36 342
c82de19312b6c3695c0c18f70709a6c535682a67 blob 4096 31 280
test-2-20f53d0edce6980dfa341c034ae365aef2616e8d.pack: ok
0be779221aca65277fd447c8207e1b3c2706ae20 blob 4096 31 311
2f22df7b2a002e7e84bd7c124483f0df7f7bc1ef commit 163 121 128
890b180ae96f7abd6a1917dee506bceb188003b6 tree 116 116 12
9d235ed07cd19811a6ceb342de82f190e49c9f68 blob 4096 31 249
b010fe5253f7dc59c6605dacb92fcea00d199d4e blob 4100 36 342
c82de19312b6c3695c0c18f70709a6c535682a67 blob 4096 31 280
test-3-20f53d0edce6980dfa341c034ae365aef2616e8d.pack: ok
* ok 16: verify pack -v
* expecting success: cat test-1-${packname_1}.idx >test-3.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
if git verify-pack test-3.idx
then false
else :;
fi
* FAIL 17: verify-pack catches mismatched .idx and .pack files
cat test-1-${packname_1}.idx >test-3.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
if git verify-pack test-3.idx
then false
else :;
fi
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=2 &&
if git verify-pack test-3.idx
then false
else :;
fi
1+0 records in
1+0 records out
1 bytes transferred in 0.000042 secs (23831 bytes/sec)
error: file test-3.pack is not a GIT packfile
fatal: packfile test-3.pack cannot be accessed
* ok 18: verify-pack catches a corrupted pack signature
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=7 &&
if git verify-pack test-3.idx
then false
else :;
fi
1+0 records in
1+0 records out
1 bytes transferred in 0.000042 secs (23831 bytes/sec)
error: packfile test-3.pack is version 0 and not supported (try upgrading GIT to a newer version)
fatal: packfile test-3.pack cannot be accessed
* ok 19: verify-pack catches a corrupted pack version
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=12 &&
if git verify-pack test-3.idx
then false
else :;
fi
1+0 records in
1+0 records out
1 bytes transferred in 0.000046 secs (21732 bytes/sec)
error: test-3.pack SHA1 checksum mismatch
error: index CRC mismatch for object 890b180ae96f7abd6a1917dee506bceb188003b6 from test-3.pack at offset 12
error: unknown object type 0 at offset 12 in test-3.pack
error: cannot unpack 890b180ae96f7abd6a1917dee506bceb188003b6 from test-3.pack at offset 12
* ok 20: verify-pack catches a corrupted type/size of the 1st packed object data
* expecting success: l=`wc -c <test-3.idx` &&
l=`expr $l - 20` &&
cat test-1-${packname_1}.pack >test-3.pack &&
dd if=/dev/zero of=test-3.idx count=20 bs=1 conv=notrunc seek=$l &&
if git verify-pack test-3.pack
then false
else :;
fi
20+0 records in
20+0 records out
20 bytes transferred in 0.000123 secs (162570 bytes/sec)
error: Packfile index for test-3.pack SHA1 mismatch
* ok 21: verify-pack catches a corrupted sum of the index file itself
* expecting success: cat test-1-${packname_1}.pack >test-3.pack &&
git index-pack -o tmp.idx test-3.pack &&
cmp tmp.idx test-1-${packname_1}.idx &&
git index-pack test-3.pack &&
cmp test-3.idx test-1-${packname_1}.idx &&
cat test-2-${packname_2}.pack >test-3.pack &&
git index-pack -o tmp.idx test-2-${packname_2}.pack &&
cmp tmp.idx test-2-${packname_2}.idx &&
git index-pack test-3.pack &&
cmp test-3.idx test-2-${packname_2}.idx &&
cat test-3-${packname_3}.pack >test-3.pack &&
git index-pack -o tmp.idx test-3-${packname_3}.pack &&
cmp tmp.idx test-3-${packname_3}.idx &&
git index-pack test-3.pack &&
cmp test-3.idx test-3-${packname_3}.idx &&
:
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
20f53d0edce6980dfa341c034ae365aef2616e8d
* ok 22: build pack index for an existing pack
* expecting success: test -f .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67 &&
cp -f .git/objects/9d/235ed07cd19811a6ceb342de82f190e49c9f68 \
.git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67
* ok 23: fake a SHA1 hash collision
* expecting success: test_must_fail git index-pack -o bad.idx test-3.pack 2>msg &&
grep "SHA1 COLLISION FOUND" msg
fatal: SHA1 COLLISION FOUND WITH c82de19312b6c3695c0c18f70709a6c535682a67 !
* ok 24: make sure index-pack detects the SHA1 collision
* expecting success: git config pack.packSizeLimit 200 &&
packname_4=$(git pack-objects test-4 <obj-list) &&
test 3 = $(ls test-4-*.pack | wc -l)
* ok 25: honor pack.packSizeLimit
* expecting success:
git config --unset pack.packsizelimit &&
for j in a b c d e f g
do
for i in 0 1 2 3 4 5 6 7 8 9
do
o=$(echo $j$i | git hash-object -w --stdin) &&
echo "100644 $o 0 $j$i"
done
done >LIST &&
rm -f .git/index &&
git update-index --index-info <LIST &&
LIST=$(git write-tree) &&
rm -f .git/index &&
head -n 10 LIST | git update-index --index-info &&
LI=$(git write-tree) &&
rm -f .git/index &&
tail -n 10 LIST | git update-index --index-info &&
ST=$(git write-tree) &&
PACK5=$( git rev-list --objects "$LIST" "$LI" "$ST" | \
git pack-objects test-5 ) &&
PACK6=$( (
echo "$LIST"
echo "$LI"
echo "$ST"
) | git pack-objects test-6 ) &&
test_create_repo test-5 &&
(
cd test-5 &&
git unpack-objects --strict <../test-5-$PACK5.pack &&
git ls-tree -r $LIST &&
git ls-tree -r $LI &&
git ls-tree -r $ST
) &&
test_create_repo test-6 &&
(
# tree-only into empty repo -- many unreachables
cd test-6 &&
test_must_fail git unpack-objects --strict <../test-6-$PACK6.pack
) &&
(
# already populated -- no unreachables
cd test-5 &&
git unpack-objects --strict <../test-6-$PACK6.pack
)
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-5/.git/
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2270a80fbb71d7109b85e7489f3f307d0141a559 0 b0
100644 blob c9c6af7f78bc47490dbf3e822cf2f3c24d4b9061 0 b1
100644 blob e6bfff5c1d0f0ecd501552b43a1e13d8008abc31 0 b2
100644 blob 6d0875c82a99774922eab07fbc08510fc85d9e0a 0 b3
100644 blob 8e953e84d803f13fd06416a1bd8161dcd93cfd00 0 b4
100644 blob 90a5159bf020296276ea5ca1bcd292a9b1de9947 0 b5
100644 blob 07eb61d36f49569a2b0649af299f9f00013d0969 0 b6
100644 blob 6e6d33cfc7b1581413a88ae0759202b25ac4cad1 0 b7
100644 blob 5d453c66b522d8de5d99c03bd2bf8b65ca0bcf33 0 b8
100644 blob 9a16e0d1a643983973291127012d2694a0b17fe8 0 b9
100644 blob caecf05cdbb03e144f113ecab2b99e5ee74df706 0 c0
100644 blob ae9304576a6ec3419b231b2b9c8e33a06f97f9fb 0 c1
100644 blob 16f9ec009e5568c435f473ba3a1df732d49ce8c3 0 c2
100644 blob 0771aea884dd394a7b12783d049f05b5599f41a4 0 c3
100644 blob a103f673dd1b7c5727aa0ae0100419adc50e1b76 0 c4
100644 blob c36357109ce20af8f90df3c0dd0784e89408d707 0 c5
100644 blob 86a716504cbdc40a135faa5ab199d15e364c416d 0 c6
100644 blob 20be68787e59f4cb8983b641d170c4baf8ea25dd 0 c7
100644 blob bb420bc8fb9e91530fdc25e363f6b822d5195309 0 c8
100644 blob f899bd1761a5ca5978799bc3189a04d3c52d8435 0 c9
100644 blob 79a5e858be4a3a969e3b71406fef0d3d36e1d387 0 d0
100644 blob 6f1852975b9306ae5d8dfdf0d4cb1f5cb36ac229 0 d1
100644 blob fd3671590780b645e1bef030d550191f6cdf1c95 0 d2
100644 blob 69c77a9ea746edd27b46107142fc2c5288c1daf5 0 d3
100644 blob d7b30ee07d4b9819a77a3b122282b4c04528ec21 0 d4
100644 blob fa590f3f8bfbef6095cf6525e8497b2b2b46445c 0 d5
100644 blob fef4390d19cb98fa97efd44c09d4e2eb7b084b40 0 d6
100644 blob a5adf29249757619b8890c86f2cfcfeee611b5d8 0 d7
100644 blob 1859919d049c078ba63fcecbce60e697c6da8e01 0 d8
100644 blob b6148c82443a60d1d5ce07872a85e3c544b5f4b0 0 d9
100644 blob 4fe4106b50b257f3d6ffd23b750d2d1945c2608b 0 e0
100644 blob 5ff91639494693b1f238b5dc9baf8be95142c3ab 0 e1
100644 blob 3811af3ca744c2fb44077a8025c23b4d4166a449 0 e2
100644 blob 9338c3fa1f74d202651154257572d32aed57cc16 0 e3
100644 blob c5195815f83aa9ef1ebac9e11f14d62b26406c99 0 e4
100644 blob 0c44c89ef9c29077cceebc6dd9ca0b3a950c95ee 0 e5
100644 blob f17172bc54cfa55a9e531cc845dff39855cd8df0 0 e6
100644 blob 29870e9ccff84f86938ee588a47b39cf3a802e6b 0 e7
100644 blob e8d01d007452cede5c6eafc3343fc80675b1e2f9 0 e8
100644 blob 0c1945ad576ffc445ad69a3fafd1d3c04cc0bd40 0 e9
100644 blob 844dc808a1d3d769ddcf5430eac933d4d87ff606 0 f0
100644 blob 8e1e71d5ce34c01b6fe83bc5051545f2918c8c2b 0 f1
100644 blob 9de77c18733ab8009a956c25e28c85fe203a17d7 0 f2
100644 blob 45d9e0e9fc8859787c33081dffdf12f41b54fcf3 0 f3
100644 blob c48ac4847d3abae8e5899dcc5cf490a98df55755 0 f4
100644 blob 14c61ecf25961ce674048103c5fa5ea3c535a5cd 0 f5
100644 blob 59ce90029dfd9e224701a040a26153e9f2feb74c 0 f6
100644 blob 0a7bd52ffb819609cf65f40eb91be62000db47e5 0 f7
100644 blob c7e617f6b429a1f3b462df6add2b4ea2cf702faf 0 f8
100644 blob a720d8c8d277ad31ee5b180bef57379b5f62517c 0 f9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-6/.git/
error: unable to find 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02
fatal: object of unexpected type
* ok 26: unpacking with --strict
* expecting success:
for j in a b c d e f g
do
for i in 0 1 2 3 4 5 6 7 8 9
do
o=$(echo $j$i | git hash-object -w --stdin) &&
echo "100644 $o 0 $j$i"
done
done >LIST &&
rm -f .git/index &&
git update-index --index-info <LIST &&
LIST=$(git write-tree) &&
rm -f .git/index &&
head -n 10 LIST | git update-index --index-info &&
LI=$(git write-tree) &&
rm -f .git/index &&
tail -n 10 LIST | git update-index --index-info &&
ST=$(git write-tree) &&
PACK5=$( git rev-list --objects "$LIST" "$LI" "$ST" | \
git pack-objects test-5 ) &&
PACK6=$( (
echo "$LIST"
echo "$LI"
echo "$ST"
) | git pack-objects test-6 ) &&
test_create_repo test-7 &&
(
cd test-7 &&
git index-pack --strict --stdin <../test-5-$PACK5.pack &&
git ls-tree -r $LIST &&
git ls-tree -r $LI &&
git ls-tree -r $ST
) &&
test_create_repo test-8 &&
(
# tree-only into empty repo -- many unreachables
cd test-8 &&
test_must_fail git index-pack --strict --stdin <../test-6-$PACK6.pack
) &&
(
# already populated -- no unreachables
cd test-7 &&
git index-pack --strict --stdin <../test-6-$PACK6.pack
)
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-7/.git/
pack df7e2e394127cb487b2a6904a9a3fa45be4d4199
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2270a80fbb71d7109b85e7489f3f307d0141a559 0 b0
100644 blob c9c6af7f78bc47490dbf3e822cf2f3c24d4b9061 0 b1
100644 blob e6bfff5c1d0f0ecd501552b43a1e13d8008abc31 0 b2
100644 blob 6d0875c82a99774922eab07fbc08510fc85d9e0a 0 b3
100644 blob 8e953e84d803f13fd06416a1bd8161dcd93cfd00 0 b4
100644 blob 90a5159bf020296276ea5ca1bcd292a9b1de9947 0 b5
100644 blob 07eb61d36f49569a2b0649af299f9f00013d0969 0 b6
100644 blob 6e6d33cfc7b1581413a88ae0759202b25ac4cad1 0 b7
100644 blob 5d453c66b522d8de5d99c03bd2bf8b65ca0bcf33 0 b8
100644 blob 9a16e0d1a643983973291127012d2694a0b17fe8 0 b9
100644 blob caecf05cdbb03e144f113ecab2b99e5ee74df706 0 c0
100644 blob ae9304576a6ec3419b231b2b9c8e33a06f97f9fb 0 c1
100644 blob 16f9ec009e5568c435f473ba3a1df732d49ce8c3 0 c2
100644 blob 0771aea884dd394a7b12783d049f05b5599f41a4 0 c3
100644 blob a103f673dd1b7c5727aa0ae0100419adc50e1b76 0 c4
100644 blob c36357109ce20af8f90df3c0dd0784e89408d707 0 c5
100644 blob 86a716504cbdc40a135faa5ab199d15e364c416d 0 c6
100644 blob 20be68787e59f4cb8983b641d170c4baf8ea25dd 0 c7
100644 blob bb420bc8fb9e91530fdc25e363f6b822d5195309 0 c8
100644 blob f899bd1761a5ca5978799bc3189a04d3c52d8435 0 c9
100644 blob 79a5e858be4a3a969e3b71406fef0d3d36e1d387 0 d0
100644 blob 6f1852975b9306ae5d8dfdf0d4cb1f5cb36ac229 0 d1
100644 blob fd3671590780b645e1bef030d550191f6cdf1c95 0 d2
100644 blob 69c77a9ea746edd27b46107142fc2c5288c1daf5 0 d3
100644 blob d7b30ee07d4b9819a77a3b122282b4c04528ec21 0 d4
100644 blob fa590f3f8bfbef6095cf6525e8497b2b2b46445c 0 d5
100644 blob fef4390d19cb98fa97efd44c09d4e2eb7b084b40 0 d6
100644 blob a5adf29249757619b8890c86f2cfcfeee611b5d8 0 d7
100644 blob 1859919d049c078ba63fcecbce60e697c6da8e01 0 d8
100644 blob b6148c82443a60d1d5ce07872a85e3c544b5f4b0 0 d9
100644 blob 4fe4106b50b257f3d6ffd23b750d2d1945c2608b 0 e0
100644 blob 5ff91639494693b1f238b5dc9baf8be95142c3ab 0 e1
100644 blob 3811af3ca744c2fb44077a8025c23b4d4166a449 0 e2
100644 blob 9338c3fa1f74d202651154257572d32aed57cc16 0 e3
100644 blob c5195815f83aa9ef1ebac9e11f14d62b26406c99 0 e4
100644 blob 0c44c89ef9c29077cceebc6dd9ca0b3a950c95ee 0 e5
100644 blob f17172bc54cfa55a9e531cc845dff39855cd8df0 0 e6
100644 blob 29870e9ccff84f86938ee588a47b39cf3a802e6b 0 e7
100644 blob e8d01d007452cede5c6eafc3343fc80675b1e2f9 0 e8
100644 blob 0c1945ad576ffc445ad69a3fafd1d3c04cc0bd40 0 e9
100644 blob 844dc808a1d3d769ddcf5430eac933d4d87ff606 0 f0
100644 blob 8e1e71d5ce34c01b6fe83bc5051545f2918c8c2b 0 f1
100644 blob 9de77c18733ab8009a956c25e28c85fe203a17d7 0 f2
100644 blob 45d9e0e9fc8859787c33081dffdf12f41b54fcf3 0 f3
100644 blob c48ac4847d3abae8e5899dcc5cf490a98df55755 0 f4
100644 blob 14c61ecf25961ce674048103c5fa5ea3c535a5cd 0 f5
100644 blob 59ce90029dfd9e224701a040a26153e9f2feb74c 0 f6
100644 blob 0a7bd52ffb819609cf65f40eb91be62000db47e5 0 f7
100644 blob c7e617f6b429a1f3b462df6add2b4ea2cf702faf 0 f8
100644 blob a720d8c8d277ad31ee5b180bef57379b5f62517c 0 f9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
100644 blob 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02 0 a0
100644 blob da0f8ed91a8f2f0f067b3bdf26265d5ca48cf82c 0 a1
100644 blob c1827f07e114c20547dc6a7296588870a4b5b62c 0 a2
100644 blob d616f7380ad325123fed6f628d02fa76e1ce77c3 0 a3
100644 blob 88ba23dca8c8529f8165539c369925a99391a4d1 0 a4
100644 blob fafec68b313bde633804c37b46810f136ee12ea6 0 a5
100644 blob 5b521d0587015867ac1a23fa00be3f3fce080b9f 0 a6
100644 blob 6bac181dd20780870c30d69308f5a90b59a15102 0 a7
100644 blob f1914bb68f8515ba7d1ab0f0cddcdf960731773d 0 a8
100644 blob dbe2bc1151e5d5d469644f20189f923f006ed0cc 0 a9
100644 blob 2e7d2f0b106eb8823e449a020497e26b86dc3eb1 0 g0
100644 blob d8a17fff13638d804e8bf7f9f357c174db98f126 0 g1
100644 blob 247c4abd244a429297a4c4b091592ae13bbf4677 0 g2
100644 blob affaa5ba8c43cfc71469226e0d57cb6823c843da 0 g3
100644 blob 51bc00f93e60aeef7dccfcf646e3f615056112bd 0 g4
100644 blob 02b4fdd23d495769852f1550c10eb015f0fe0039 0 g5
100644 blob e65aa9d64b596da2ba61e0662b1173f1e16dcbcf 0 g6
100644 blob e19089689a05907b359f52c972ee7d2294fa96ab 0 g7
100644 blob 30c2af9542d38e1f248390632612e0fb944fd27d 0 g8
100644 blob 09827d7e43d81089e868e9f0f06502b865939c05 0 g9
Initialized empty Git repository in /home/peff/compile/gitbuild/jk/freebsd/project/t/trash directory.t5300-pack-object/test-8/.git/
error: unable to find 0042f6c56d8fc1896f3efc2cdc5060e5b5e44e02
fatal: object of unexpected type
pack f67e682280757d6079b87511ea590015d0e26770
* ok 27: index-pack with --strict
* expecting success:
git config pack.packSizeLimit 2 &&
packname_9=$(git pack-objects test-9 <obj-list) &&
test $(wc -l <obj-list) = $(ls test-9-*.pack | wc -l)
* ok 28: tolerate absurdly small packsizelimit
* failed 2 among 28 test(s)
^ permalink raw reply
* Re: Saving patches from this list
From: Stefan Näwe @ 2008-12-13 13:28 UTC (permalink / raw)
To: git
In-Reply-To: <20081212151419.GL32487@spearce.org>
Shawn O. Pearce <spearce <at> spearce.org> writes:
> > > > > What's the best way to get patches sent to this list in a form suitable
> > > > > for 'git am' without subscribing to this list ?
>
> If you find the article on the web with gmane, add '/raw' onto the
> end of direct link URL. E.g. to get:
>
> http://article.gmane.org/gmane.comp.version-control.git/102874
>
> use:
>
> curl http://article.gmane.org/gmane.comp.version-control.git/102874/raw |
git am
Now that was helpful!
Exactly what I was looking for!
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Wu Fengguang @ 2008-12-13 13:17 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git@vger.kernel.org, Boyd Stephen Smith Jr.
In-Reply-To: <20081213044357.GD15407@josefsipek.net>
Hi Jeff,
On Sat, Dec 13, 2008 at 06:43:57AM +0200, Josef Jeff Sipek wrote:
> On Sat, Dec 13, 2008 at 10:14:22AM +0800, Wu Fengguang wrote:
> > Introduce option guilt.diffstat so that we don't have to type
> > "guilt refresh --diffstat" in its full form every time.
>
> Good idea.
Thanks.
> Could you throw a quick note into the manpages?
Sure. Here is the updated patch. This time I used "git-config --bool"
to ensure diffstat will be either "true" or "false":
The type specifier can be either --int or --bool, which will
make git-config ensure that the variable(s) are of the given
type and convert the value to the canonical form (simple
decimal number for int, a "true" or "false" string for bool).
If no type specifier is passed, no checks or transformations
are performed on the value.
Thanks,
Fengguang
---
guilt: add option guilt.diffstat
Introduce option guilt.diffstat so that we don't have to type
"guilt refresh --diffstat" in its full form every time.
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
---
diff --git a/Documentation/guilt-refresh.txt b/Documentation/guilt-refresh.txt
index 9a0b4e8..7757bdc 100644
--- a/Documentation/guilt-refresh.txt
+++ b/Documentation/guilt-refresh.txt
@@ -20,8 +20,14 @@ OPTIONS
format (e.g., rename and copy detection).
--diffstat::
- Include a diffstat output in the patch file. Useful for cases where
- patches will be submitted with other tools.
+Include a diffstat output in the patch file. Useful for cases where
+patches will be submitted with other tools.
++
+If the command line option is omitted, the corresponding git-config
+option "guilt.diffstat" will be queried. So this would enable diffstat
+output by default:
+
+ git config --global guilt.diffstat true
Author
------
diff --git a/guilt b/guilt
index fabee17..12361da 100755
--- a/guilt
+++ b/guilt
@@ -544,7 +544,7 @@ __refresh_patch()
[ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
- if [ ! -z "$5" ]; then
+ if [ -n "$5" -o $diffstat = "true" ]; then
(
echo "---"
git diff --stat $diffopts "$2"
@@ -633,6 +633,9 @@ guilt_push_diff_context=1
# default autotag value
AUTOTAG_DEFAULT=1
+# default diffstat value: true or false
+DIFFSTAT_DEFAULT="false"
+
#
# Parse any part of .git/config that belongs to us
#
@@ -641,6 +644,10 @@ AUTOTAG_DEFAULT=1
autotag=`git config guilt.autotag`
[ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
+# generate diffstat?
+diffstat=`git config --bool guilt.diffstat`
+[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
+
#
# The following gets run every time this file is source'd
#
^ permalink raw reply related
* [patch] Fix a corner case in git update-index --index-info
From: Thomas Jarosch @ 2008-12-13 13:03 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Fix a corner case in git update-index --index-info:
If there are no input lines, it won't create an empty index.
Here's a short test for this:
echo -n "" |GIT_INDEX_FILE=index.new git update-index --index-info
-> The index "index.new" won't get created
It failed for me while I was using
git filter-branch as described in the man page:
git filter-branch --index-filter \
´git ls-files -s | sed "s-\t-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE´ HEAD
The conversion aborted because the first commit was empty.
(created by cvs2svn)
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 65d5775..998a48e 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -299,6 +299,7 @@ static void read_index_info(int line_termination)
{
struct strbuf buf = STRBUF_INIT;
struct strbuf uq = STRBUF_INIT;
+ int found_something = 0;
while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
char *ptr, *tab;
@@ -308,6 +309,8 @@ static void read_index_info(int line_termination)
unsigned long ul;
int stage;
+ found_something = 1;
+
/* This reads lines formatted in one of three formats:
*
* (1) mode SP sha1 TAB path
@@ -383,6 +386,11 @@ static void read_index_info(int line_termination)
bad_line:
die("malformed index info %s", buf.buf);
}
+
+ /* Force creation of empty index - needed by git filter-branch */
+ if (!found_something)
+ active_cache_changed = 1;
+
strbuf_release(&buf);
strbuf_release(&uq);
}
^ permalink raw reply related
* Re: [JGIT PATCH 2/2] Add getPatchText functions to obtain the plain-text version of a patch
From: Robin Rosenberg @ 2008-12-13 11:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1229136146-15359-2-git-send-email-spearce@spearce.org>
lördag 13 december 2008 03:42:26 skrev Shawn O. Pearce:
> The conversion from byte[] to String is performed one line at a time,
> in case the patch is a character encoding conversion patch for the
> file. For simplicity we currently assume UTF-8 still as the default
> encoding for any content, but eventually we should support using the
> .gitattributes encoding property when performing this conversion.
For usefulness we must be able to pass the encoding from outside,
e.g. the encoding Eclipse uses, which often is not UTF-8-
-- robin
^ permalink raw reply
* Re: characterizing commits
From: Jeff King @ 2008-12-13 8:52 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <4943721C.7070200@gmail.com>
On Sat, Dec 13, 2008 at 08:28:12AM +0000, William Pursell wrote:
> A lot of commits in any given project can be grouped into
> different types. eg, looking at the history for git,
> there are a lot of merge commits, a lot of commits
> that only touch gitk, a lot of 'auto-generated manpages',
> a lot of 'typo in documentation' etc. In my own
> projects, I have a fairly high percentage of commits
> that are trivial (eg whitespace only, typos, etc).
> What I'm after is the ability to do something like:
>
> git log --group=!trivial
> git log --group=importance:3+
>
> [...]
> Is there already a mechanism for filtering
> commits that I could extend to accomplish this?
Generally you would put a pseudo-header into your commit message, like:
Status: trivial
Importance: 3
and then use --grep to filter matching commits:
git log --grep="Status: trivial"
git log --grep="Importance: [3-9]"
Obviously the syntax is a little bit clunkier. You could fix that with
an option to parse arbitrary pseudo-headers (and even support numeric
relations), something like:
git log --filter='importance > 3'
which would be converted internally to a grep of the commit message like
this:
/^importance: (\d+)/i
and compare the result to 3.
The nice thing about that approach is that the storage remains the same:
text in the commit message. That means it gets displayed when you look
at the commit, people with older versions of git can still read it, etc.
One thing this _doesn't_ get you is annotating commits after the fact.
This has been discussed in the past; try searching the list for "notes".
-Peff
^ permalink raw reply
* Announce: TortoiseGit 0.1 preview version
From: 李智 @ 2008-12-13 8:33 UTC (permalink / raw)
To: git
TortoiseGit is porting from TortoiseSVN. It is explore extension.
This version just finish a min set of TortoiseSVN porting
1.Context menu(subset of TortoiseSVN)
2.Icon Overlay(version controled\unversion controled at directory)
3.Unified DIFF
4.Use third part diff tools (such as kdiff3)
5.Commit change
6.Show Log
7.Create Repository
Project Home Page at:
http://code.google.com/p/tortoisegit/
Source code at
http://repo.or.cz/w/TortoiseGit.git
It need msysgit 1.6.0.2.
^ permalink raw reply
* characterizing commits
From: William Pursell @ 2008-12-13 8:28 UTC (permalink / raw)
To: git
I have a desire to add metadata to commits to characterize
their importance/type. (Or I'd like another recommended
method to achieve the following behavior).
A lot of commits in any given project can be grouped into
different types. eg, looking at the history for git,
there are a lot of merge commits, a lot of commits
that only touch gitk, a lot of 'auto-generated manpages',
a lot of 'typo in documentation' etc. In my own
projects, I have a fairly high percentage of commits
that are trivial (eg whitespace only, typos, etc).
What I'm after is the ability to do something like:
git log --group=!trivial
git log --group=importance:3+
and only get the log for those commits that have been
not been classified "trivial" or that have a precedence
of 3 or greater.
For example, I'd like the following work flow:
$ git log --pretty=oneline
e62bb07a6894d282cdc0fdba6c67ae2ecd086cbb 5
b0986c6e8415c45e123e1838fbe8bf9e8518a90d 4
89916e36bae3208a76c338e91508759787563042 3
3942ef4e118dde3d844da5d84f466ac9666fae62 2
6fa2e40ed491d1dcbbfac9f2d301b517413bec3b 1
04dcd38a8cb6496e37594a273ca39542912ca1eb important
9bd23c2d08e254058a1a9709f963737dc9a71d16 trivial change
$ git group 6fa2e trivial
$ git group 9bd23 trivial
$ git log --pretty=oneline --group=!trivial
e62bb07a6894d282cdc0fdba6c67ae2ecd086cbb 5
b0986c6e8415c45e123e1838fbe8bf9e8518a90d 4
89916e36bae3208a76c338e91508759787563042 3
3942ef4e118dde3d844da5d84f466ac9666fae62 2
04dcd38a8cb6496e37594a273ca39542912ca1eb important
Is there already a mechanism for filtering
commits that I could extend to accomplish this?
--
William Pursell
^ permalink raw reply
* Re: [PATCH v2] git-branch: display sha1 on branch deletion
From: Jeff King @ 2008-12-13 6:31 UTC (permalink / raw)
To: Brandon Casey; +Cc: gitster, git
In-Reply-To: <UfCPFu_boLV0ycLKLmOno8GTqmtC4RSZZ9O6aRLGYjmSZOdKv6ywhCjApnplTHLxUIzO8KJ5Mww@cipher.nrlssc.navy.mil>
On Fri, Dec 12, 2008 at 05:20:07PM -0600, Brandon Casey wrote:
> Make it easier to recover from a mistaken branch deletion by displaying the
> sha1 of the branch's tip commit.
This version looks fine to me, but one nit:
> - test "$(git branch -d my7 2>&1)" = "Deleted branch my7."'
> + sha1=$(git rev-parse my7 | cut -c 1-7) &&
> + test "$(git branch -d my7 2>&1)" = "Deleted branch my7 ($sha1)."'
There is a very very small chance that this sha1 might require more
than 7 characters to be unique (small because we have such a tiny number
of objects in the trash repo). Maybe:
sha1=$(git log --pretty=format:%h -1 my7)
is better (though I have to admit, if I were writing the test originally
I would have tested the exit value of "git branch" instead of the
message).
-Peff
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Josef Jeff Sipek @ 2008-12-13 6:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Wu Fengguang, git
In-Reply-To: <200812130018.56061.bss03@volumehost.net>
On Sat, Dec 13, 2008 at 12:18:50AM -0600, Boyd Stephen Smith Jr. wrote:
> On Friday 2008 December 12 22:43:57 Josef Jeff Sipek wrote:
> >> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
> >
> >Why the 'x' thing? I've seen it is some scripts before, but I can't think of
> >a reason to use it if the variable is surrounded in quotation marks.
>
> '[' or test see the arguments after they are unquoted (normally). So,
> if "$diffstat" is "-n" it might try and do the -n test, rather than the =
> test.
Oh. I haven't even thought of that posibility!
> It could be re-written as "1" == "${diffstat}" instead to avoid the x, but
> it's not a big deal (to me). That also looks backwards to a lot of people.
Including me.
Thanks for the info.
Josef 'Jeff' Sipek.
--
Penguin : Linux version 2.6.25.4 on an i386 machine (6135.73 BogoMips).
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Boyd Stephen Smith Jr. @ 2008-12-13 6:18 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: Wu Fengguang, git
In-Reply-To: <20081213044357.GD15407@josefsipek.net>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Friday 2008 December 12 22:43:57 Josef Jeff Sipek wrote:
>> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
>
>Why the 'x' thing? I've seen it is some scripts before, but I can't think of
>a reason to use it if the variable is surrounded in quotation marks.
'[' or test see the arguments after they are unquoted (normally). So,
if "$diffstat" is "-n" it might try and do the -n test, rather than the =
test.
It could be re-written as "1" == "${diffstat}" instead to avoid the x, but
it's not a big deal (to me). That also looks backwards to a lot of people.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Junio C Hamano @ 2008-12-13 5:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Howells, torvalds, git, linux-kernel
In-Reply-To: <4942C2D1.4090309@garzik.org>
Jeff Garzik <jeff@garzik.org> writes:
> What do you feel is missing from the Kernel Hackers' Guide to Git? :)
>
> http://linux.yyz.us/git-howto.html
>
> Jeff
For a starter, it is not in-tree ;-).
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-13 5:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Daniel Barkalow, Shawn O. Pearce, Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812120813m2949e36ar7905d5688b8f6ecb@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 12/12/08, Junio C Hamano <gitster@pobox.com> wrote:
>> So "git grep -e frotz Documentation/", whether you only check out
>> Documentation or the whole tree, should grep only in Documentation area,
>> and "git grep -e frotz" should grep in the whole tree, even if you happen
>> to have a sparse checkout. By definition, a sparse checkout has no
>> modifications outside the checkout area, so whenever grep wants to look
>> for strings outside the checkout area it should pretend as if the same
>> content as what the index records is in the work tree. This is consistent
>> with the way how "git diff" in a sparsely checked out work tree should
>> behave.
>
> Assume someone is using sparse checkout with KDE git repository. They
> sparse-checkout kdeutils module and do "git grep -e foo". I would
> expect that the command only searches in kdeutils only (and is the
> current behavior).
Yes it is the "current in next" behaviour, and no that is not what you
should expect, and that is why I earlier said it is a mistake. The
ability to choose which part to leave out of the working tree should not
change the fact that git is about managing the history of the whole tree,
not an individual file nor a subset of files.
I do not think it is unreasonable to have a mechanism to let the user
limit the area of the whole tree often used Porcelain commands look at.
We already have pathspec "git grep -e foo kdeutils/" mechanism that lets
you do such limiting. It is conceivable that some workflows _might_ find
having the default pathspec convenient in end-user initiated operations,
but then it would be convenient whether the end-user uses the sparse
checkout to limit the area to kdeutils/ or has the whole checkout.
Although I think it would be Okay to default the default pathspec match
the checkout area when the sparse checkout feature is in use, I think the
"checkout area" and "area of interest" should be two independent concepts.
I said "_might_" in the above because I do not think it is such a good
idea to have _the_ default pathspec to begin with, though. It would
probably be more useful to allow people to use shorthands to pathspecs,
and at that point you can use usual shell variables to do that already,
e.g. instead of having to say "git grep -e foo arch/x86 include/asm-i386",
you would say "git grep -e foo $i386", after "i386=arch/x86 include/asm-i386",
or something like that.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #06; Wed, 26)
From: Junio C Hamano @ 2008-12-13 5:51 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Johannes Sixt, Junio C Hamano, Daniel Barkalow, Shawn O. Pearce,
Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0812120854k1c366327o9bc696184ea4f02e@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> On 12/12/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> ...
>> But what if the same persion notices a #define in a kdeutils header file
>> and want's to know whether it is unused in order to remove it:
>>
>> $ git grep FOO
>> kdeutils/foo.h:#define FOO bar
>
> "git grep --cached FOO" ?
That should behave identically when the work tree does not have change
since the index, and by definition paths outside the checkout area in the
"sparse" mode cannot have changes, so "git grep FOO" should behave the
same and should find it.
^ permalink raw reply
* Re: [PATCH] guilt: add option guilt.diffstat
From: Josef Jeff Sipek @ 2008-12-13 4:43 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git
In-Reply-To: <20081213021422.GA28249@localhost>
On Sat, Dec 13, 2008 at 10:14:22AM +0800, Wu Fengguang wrote:
> Introduce option guilt.diffstat so that we don't have to type
> "guilt refresh --diffstat" in its full form every time.
Good idea.
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> ---
> guilt | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> --- guilt.orig 2008-12-13 09:53:32.000000000 +0800
> +++ guilt 2008-12-13 10:01:03.000000000 +0800
> @@ -538,7 +538,7 @@ __refresh_patch()
>
> [ ! -z "$4" ] && diffopts="-C -M --find-copies-harder"
>
> - if [ ! -z "$5" ]; then
> + if [ -n "$5" -o "x$diffstat" = "x1" ]; then
Why the 'x' thing? I've seen it is some scripts before, but I can't think of
a reason to use it if the variable is surrounded in quotation marks.
> (
> echo "---"
> git diff --stat $diffopts "$2"
> @@ -627,6 +627,9 @@ guilt_push_diff_context=1
> # default autotag value
> AUTOTAG_DEFAULT=1
>
> +# default diffstat value
> +DIFFSTAT_DEFAULT=0
> +
> #
> # Parse any part of .git/config that belongs to us
> #
> @@ -635,6 +638,10 @@ AUTOTAG_DEFAULT=1
> autotag=`git config guilt.autotag`
> [ -z "$autotag" ] && autotag=$AUTOTAG_DEFAULT
>
> +# generate diffstat?
> +diffstat=`git config guilt.diffstat`
> +[ -z "$diffstat" ] && diffstat=$DIFFSTAT_DEFAULT
> +
> #
> # The following gets run every time this file is source'd
> #
Could you throw a quick note into the manpages?
Thanks,
Josef 'Jeff' Sipek.
--
My public GPG key can be found at
http://www.josefsipek.net/gpg/public-0xC7958FFE.txt
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Junio C Hamano @ 2008-12-13 3:35 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <20081212182827.28408.40963.stgit@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> writes:
> Add a guide to using GIT's simpler features.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
>
> Documentation/git-haters-guide.txt | 1283 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 1283 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/git-haters-guide.txt
>
>
> diff --git a/Documentation/git-haters-guide.txt b/Documentation/git-haters-guide.txt
> new file mode 100644
> index 0000000..51e4dac
> --- /dev/null
> +++ b/Documentation/git-haters-guide.txt
> @@ -0,0 +1,1283 @@
> + ===================================
> + THE GIT HATER'S GUIDE TO THE GALAXY
> + ===================================
> +
> +By David Howells <dhowells@redhat.com>
> +
> +Contents:
> ...
> +============
> +INTRODUCTION
> +============
> +
> +So, you want to do some Linux kernel development? And you hear there's this
> +piece of software called 'GIT' that you probably ought to be using when dealing
> +with the kernel community? Then you find out that not only was Linux started
> +by this Linus Torvalds person, but GIT was too! Perhaps it doesn't seem fair:
> +Linus has not just _one_ huge piece of software named after himself, but _two_!
> +And on top of that, globe spanning hardware vendors just queue up to give him
> +all the herring he can eat!!
> +
> +Then you look at webpages about GIT. You look at the manpages! You run the
> +commands with --help! And you *still* don't know how to do anything complex
> +with it!! You feel certain that there's some secret rite you have to perform
> +to become a GIT initiate - probably something involving two goats, an altar and
> +a full moon - oh, and lots of beer (we *are* talking about kernel developers
> +after all).
> +
> +Then you ask around, and people look at you blankly, hedge or say that it's
> +easy and obvious (they should know - they wrote the damned thing). You realise
> +that the manpages are more an aide-memoire and that what you really want is
> +some sort of crib sheet; something that can hold your hand whilst you cut and
> +paste things from of it until you can see the point.
> +
> +Well, let's see if I can help...
> +
> +
> +DISCLAIMER
> +----------
> +
> +I don't really know what I'm doing with GIT...
I think this patch is good up to this point. It is mildly funny and there
would exist some people who share the same sense of humor as the above
paragraphs (I am unfortunately one of them, though).
I've only skimmed the remainder of the patch, and found there are quite a
few technical errors and deviations from standard terminologies that I do
not care to enumerate (I do not have infinite amount of time). They make
me suspect that anybody who tries to learn from this document would be
harmed rather than helped in the longer run.
The document could be a good addition if the remainder of the patch is
replaced by a collection of links to better introductory documents that
are already available on the net, IMHO.
^ permalink raw reply
* Re: [PATCH] Simplified GIT usage guide
From: Miklos Vajna @ 2008-12-13 3:34 UTC (permalink / raw)
To: David Howells; +Cc: torvalds, git, linux-kernel
In-Reply-To: <32096.1229130776@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On Sat, Dec 13, 2008 at 01:12:56AM +0000, David Howells <dhowells@redhat.com> wrote:
> Okay. I do mention tags. How they're stored in the database is irrelevant.
> As far as most users need be concerned, a tag is a symbolic representation of
> a particular commit in the tree; a particular state of the source tree.
Actually I think it matters, that's why a 'tag' differs to a 'tag
object'. Also, a tag can point to any other object, not just to a
commit. (Though usually it does.)
> Think of symbolic links as an analogy. Most users just need to know that a
> symlink represents the location of another part of the VFS tree; actually most
> users will just think of them as a pointer to the name of a file, if even that
> much. The fact that, say, ReiserFS tail packs them because they tend to be
> small, or that AFS symlinks have weird properties that encode mountpoints is
> irrelevant to most users. You don't need to know that to use them.
Won't it be confusing that a symlink can be stored as a blob, tags are
refs, but refs are not blobs?
> Yes, GIT's database has blob objects, tree objects, commit objects and tag
> objects; but as far as the normal user is concerned, it stores files, lists of
> files (directories or, more probably, folders), commits and tags. The
> physical low-level stuff is completely irrelevant.
Agreed, the object database is not interesting for a beginner.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: gitweb and unicode special characters
From: Edward Z. Yang @ 2008-12-13 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <200812130231.06929.jnareb@gmail.com>
Jakub Narebski wrote:
> Sidenote: There is probably one exception we want to add, namely not
> escape '\r' at the end of line, to be able to deal better with DOS
> line endings (\r\n).
I'm sorry, but I have to disagree. I find being able to see \r
line-endings in the pretty-printed format is exceedingly useful for
figuring out if a file has been checked in with the wrong line-endings.
The number of files that must have \r line endings are vanishingly small
(Bat files are perhaps the one example I can think of right now).
Cheers,
Edward
^ permalink raw reply
* [JGIT PATCH 2/2] Add getPatchText functions to obtain the plain-text version of a patch
From: Shawn O. Pearce @ 2008-12-13 2:42 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1229136146-15359-1-git-send-email-spearce@spearce.org>
The conversion from byte[] to String is performed one line at a time,
in case the patch is a character encoding conversion patch for the
file. For simplicity we currently assume UTF-8 still as the default
encoding for any content, but eventually we should support using the
.gitattributes encoding property when performing this conversion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/patch/BinaryHunk.java | 8 ++
| 6 ++
| 7 ++
.../src/org/spearce/jgit/patch/PatchUtil.java | 79 ++++++++++++++++++++
4 files changed, 100 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
index f43a1b9..f4e2ee3 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/BinaryHunk.java
@@ -42,6 +42,8 @@
import static org.spearce.jgit.util.RawParseUtils.nextLF;
import static org.spearce.jgit.util.RawParseUtils.parseBase10;
+import org.spearce.jgit.lib.Constants;
+
/** Part of a "GIT binary patch" to describe the pre-image or post-image */
public class BinaryHunk {
private static final byte[] LITERAL = encodeASCII("literal ");
@@ -96,6 +98,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getHunkText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/** @return type of this binary hunk */
public Type getType() {
return type;
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
index 7c3a45a..0110f4a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/FileHeader.java
@@ -188,6 +188,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getScriptText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/**
* Get the old name associated with this file.
* <p>
--git a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
index 12c670d..5a3b590 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/HunkHeader.java
@@ -42,6 +42,7 @@
import static org.spearce.jgit.util.RawParseUtils.parseBase10;
import org.spearce.jgit.lib.AbbreviatedObjectId;
+import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.util.MutableInteger;
/** Hunk header describing the layout of a single block of lines */
@@ -138,6 +139,12 @@ public int getEndOffset() {
return endOffset;
}
+ /** @return text of this patch file's script; best-effort decoded */
+ public String getHunkText() {
+ return PatchUtil.decode(Constants.CHARSET, getBuffer(),
+ getStartOffset(), getEndOffset());
+ }
+
/** @return information about the old image mentioned in this hunk. */
public OldImage getOldImage() {
return old;
diff --git a/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java b/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
new file mode 100644
index 0000000..89136c0
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/patch/PatchUtil.java
@@ -0,0 +1,79 @@
+/*
+ * Copyright (C) 2008, Google Inc.
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.patch;
+
+import java.nio.charset.Charset;
+
+import org.spearce.jgit.util.RawParseUtils;
+
+/** Patch related utility functions. */
+public class PatchUtil {
+ /**
+ * Decode a region of a buffer one line at a time.
+ * <p>
+ * Unlike {@link RawParseUtils#decode(Charset, byte[], int, int)} this
+ * method reads the input one line at a time and decodes each line
+ * individually. This permits a decoding of a file converting from
+ * ISO-8859-1 to UTF-8 encoding (for example), as each line in the patch
+ * script will be in one encoding or the other.
+ *
+ * @param cs
+ * preferred character set to use when decoding the buffer.
+ * @param buf
+ * buffer to pull the raw bytes from.
+ * @param ptr
+ * first position to read.
+ * @param end
+ * one position past the last position to read.
+ * @return a string representation of the region, decoded per-line.
+ */
+ public static String decode(final Charset cs, final byte[] buf, int ptr,
+ final int end) {
+ final StringBuilder r = new StringBuilder(end - ptr);
+ while (ptr < end) {
+ final int eol = Math.min(end, RawParseUtils.nextLF(buf, ptr));
+ r.append(RawParseUtils.decode(cs, buf, ptr, eol));
+ ptr = eol;
+ }
+ return r.toString();
+ }
+
+ private PatchUtil() {
+ // No instances
+ }
+}
--
1.6.1.rc2.306.ge5d5e
^ 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