* Re: [usability bug] git branch -a does not disambiguate remote and local branches
From: Johannes Schindelin @ 2008-12-15 19:09 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812151015t4d5bc2b8p4ea53a0e4ad25e64@mail.gmail.com>
Hi,
On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
> Let's consider the following scenario:
>
> mkdir bare.git
> mkdir local
> cd bare.git
> git --bare init
> cd ../local
> git init
> echo test > test.txt
> git add test.txt
> git commit -m test
> git remote add origin `pwd`/../bare.git
> git push --all
> git checkout -b origin/master master
> echo updated > test.txt
> git add test.txt
> git commit -m updated
>
> Note that that in this scenario, the user has created local branch in
> the folder with the same name as a remote branch. While the supposed
> user here is apparently shooting itself in the foot, the scenario is
> still supported by git, and might happen as a result of more logical
> git operations (like git fetch).
It is only half-supported, and Git will complain, saying that there are
ambiguous branches.
IMHO it is better to be nice to the many users who do not try to shoot
themselves in the foot, by showing them the nice short names that will
work.
The others are warned when they use the ambiguous short names anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] pack-objects: don't use too many threads with few objects
From: Mike Ralphson @ 2008-12-15 18:38 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0812131456040.30035@xanadu.home>
2008/12/13 Nicolas Pitre <nico@cam.org>
>
> If there are few objects to deltify, they might be split amongst threads
> so that there is simply no other objects left to delta against within
> the same thread. Let's use the same 2*window treshold as used for the
> final load balancing to allow extra threads to be created.
>
> This fixes the benign t5300 test failure.
Even with this I'm seeing failures in t5302 which I think are probably
related to 43cc2b42
I was trying to bisect it (test runs take forever on this platform -
AIX 5.3) but I hit the t5300 failure, which I hadn't seen on the last
automatic build.
Please shout if I've snipped the vital lines (...)
Initialized empty Git repository in /usr/local/src/gitbuild/t/trash
directory.t5302-pack-index/.git/
* expecting success: rm -rf .git
git init &&
i=1 &&
while test $i -le 100
do
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 &&
tree=`git write-tree` &&
commit=`git commit-tree $tree </dev/null` && {
echo $tree &&
git ls-tree $tree | sed -e "s/.* \\([0-9a-f]*\\) .*/\\1/"
} >obj-list &&
git update-ref HEAD $commit
Initialized empty Git repository in /usr/local/src/gitbuild/t/trash
directory.t5302-pack-index/.git/
* ok 1: setup
* expecting success: pack1=$(git pack-objects --index-version=1 test-1
<obj-list) &&
git verify-pack -v "test-1-${pack1}.pack"
0106e17481932f5c223fafadc1d26abc6adf40d6 blob 57 90 850703 1
69e0b8ef8cda369575b6801c6ed47daf09aa3c62
...
fff3a3a92d2268a464dbdcd00fc055885ee3cba9 blob 8196 8210 187576
chain length = 1: 110 objects
chain length = 2: 11 objects
chain length = 3: 11 objects
chain length = 4: 10 objects
chain length = 5: 9 objects
chain length = 6: 9 objects
chain length = 7: 9 objects
chain length = 8: 9 objects
chain length = 9: 9 objects
test-1-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: ok
* ok 2: pack-objects with index version 1
* expecting success: pack2=$(git pack-objects --index-version=2 test-2
<obj-list) &&
git verify-pack -v "test-2-${pack2}.pack"
0106e17481932f5c223fafadc1d26abc6adf40d6 blob 57 90 850531 1
69e0b8ef8cda369575b6801c6ed47daf09aa3c62
...
fff3a3a92d2268a464dbdcd00fc055885ee3cba9 blob 8196 8210 187404
chain length = 1: 109 objects
chain length = 2: 10 objects
chain length = 3: 10 objects
chain length = 4: 10 objects
chain length = 5: 10 objects
chain length = 6: 10 objects
chain length = 7: 10 objects
chain length = 8: 10 objects
chain length = 9: 9 objects
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: ok
* ok 3: pack-objects with index version 2
* expecting success: cmp "test-1-${pack1}.pack" "test-2-${pack2}.pack"
test-1-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack differ: char
10236, line 32
* FAIL 4: both packs should be identical
cmp "test-1-${pack1}.pack" "test-2-${pack2}.pack"
* expecting success: ! cmp "test-1-${pack1}.idx" "test-2-${pack2}.idx"
test-1-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx differ: char 1,
line 1
* ok 5: index v1 and index v2 should be different
* expecting success: git index-pack --index-version=1 -o 1.idx
"test-1-${pack1}.pack"
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 6: index-pack with index version 1
* expecting success: git index-pack --index-version=2 -o 2.idx
"test-1-${pack1}.pack"
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 7: index-pack with index version 2
* expecting success: cmp "test-1-${pack1}.idx" "1.idx" &&
cmp "test-2-${pack2}.idx" "2.idx"
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx 2.idx differ: char
7273, line 23
* FAIL 8: index-pack results should match pack-objects ones
cmp "test-1-${pack1}.idx" "1.idx" &&
cmp "test-2-${pack2}.idx" "2.idx"
* expecting success: pack3=$(git pack-objects
--index-version=2,0x40000 test-3 <obj-list)
* ok 9: index v2: force some 64-bit offsets with pack-objects
* expecting success: git verify-pack -v "test-3-${pack3}.pack"
0106e17481932f5c223fafadc1d26abc6adf40d6 blob 57 90 850531 1
69e0b8ef8cda369575b6801c6ed47daf09aa3c62
...
fff3a3a92d2268a464dbdcd00fc055885ee3cba9 blob 8196 8210 187404
chain length = 1: 109 objects
chain length = 2: 10 objects
chain length = 3: 10 objects
chain length = 4: 10 objects
chain length = 5: 10 objects
chain length = 6: 10 objects
chain length = 7: 10 objects
chain length = 8: 10 objects
chain length = 9: 9 objects
test-3-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: ok
* ok 10: index v2: verify a pack with some 64-bit offsets
* expecting success: ! cmp "test-2-${pack2}.idx" "test-3-${pack3}.idx"
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
test-3-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx differ: char 8281,
line 24
* ok 11: 64-bit offsets: should be different from previous index v2 results
* expecting success: git index-pack --index-version=2,0x40000 -o 3.idx
"test-1-${pack1}.pack"
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 12: index v2: force some 64-bit offsets with index-pack
* expecting success: cmp "test-3-${pack3}.idx" "3.idx"
test-3-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx 3.idx differ: char
7273, line 23
* FAIL 13: 64-bit offsets: index-pack result should match pack-objects one
cmp "test-3-${pack3}.idx" "3.idx"
* expecting success: git index-pack --index-version=1 --stdin <
"test-1-${pack1}.pack" &&
git prune-packed &&
git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
cmp "test-1-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"
pack 9108b6dfd43bf36ccbfc2839fe62d1503bf84292
Removing duplicate objects: 25% (65/256)
Removing duplicate objects: 26% (68/256)
Removing duplicate objects: 27% (71/256)
Removing duplicate objects: 28% (74/256)
Removing duplicate objects: 30% (79/256)
Removing duplicate objects: 31% (81/256)
Removing duplicate objects: 32% (83/256)
Removing duplicate objects: 33% (85/256)
Removing duplicate objects: 34% (88/256)
Removing duplicate objects: 35% (90/256)
Removing duplicate objects: 36% (93/256)
Removing duplicate objects: 37% (95/256)
Removing duplicate objects: 38% (98/256)
Removing duplicate objects: 39% (100/256)
Removing duplicate objects: 40% (103/256)
Removing duplicate objects: 41% (106/256)
Removing duplicate objects: 42% (108/256)
Removing duplicate objects: 43% (112/256)
Removing duplicate objects: 44% (114/256)
Removing duplicate objects: 45% (116/256)
Removing duplicate objects: 46% (118/256)
Removing duplicate objects: 47% (121/256)
Removing duplicate objects: 48% (124/256)
Removing duplicate objects: 50% (130/256)
Removing duplicate objects: 51% (132/256)
Removing duplicate objects: 52% (134/256)
Removing duplicate objects: 53% (136/256)
Removing duplicate objects: 54% (140/256)
Removing duplicate objects: 55% (141/256)
Removing duplicate objects: 56% (144/256)
Removing duplicate objects: 57% (146/256)
Removing duplicate objects: 57% (147/256)
Removing duplicate objects: 58% (149/256)
Removing duplicate objects: 60% (154/256)
Removing duplicate objects: 61% (157/256)
Removing duplicate objects: 62% (159/256)
Removing duplicate objects: 63% (163/256)
Removing duplicate objects: 64% (164/256)
Removing duplicate objects: 65% (167/256)
Removing duplicate objects: 66% (169/256)
Removing duplicate objects: 67% (172/256)
Removing duplicate objects: 68% (175/256)
Removing duplicate objects: 69% (177/256)
Removing duplicate objects: 70% (180/256)
Removing duplicate objects: 71% (182/256)
Removing duplicate objects: 72% (185/256)
Removing duplicate objects: 73% (187/256)
Removing duplicate objects: 74% (190/256)
Removing duplicate objects: 75% (192/256)
Removing duplicate objects: 76% (195/256)
Removing duplicate objects: 77% (198/256)
Removing duplicate objects: 78% (201/256)
Removing duplicate objects: 79% (204/256)
Removing duplicate objects: 80% (206/256)
Removing duplicate objects: 81% (208/256)
Removing duplicate objects: 82% (210/256)
Removing duplicate objects: 83% (215/256)
Removing duplicate objects: 84% (217/256)
Removing duplicate objects: 85% (218/256)
Removing duplicate objects: 86% (222/256)
Removing duplicate objects: 87% (223/256)
Removing duplicate objects: 88% (226/256)
Removing duplicate objects: 89% (228/256)
Removing duplicate objects: 90% (231/256)
Removing duplicate objects: 91% (233/256)
Removing duplicate objects: 92% (236/256)
Removing duplicate objects: 93% (240/256)
Removing duplicate objects: 94% (241/256)
Removing duplicate objects: 95% (245/256)
Removing duplicate objects: 96% (246/256)
Removing duplicate objects: 97% (249/256)
Removing duplicate objects: 98% (251/256)
Removing duplicate objects: 99% (254/256)
Removing duplicate objects: 100% (256/256)
Removing duplicate objects: 100% (256/256), done.
* ok 14: [index v1] 1) stream pack to repository
* expecting success: # 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
20+0 records in
20+0 records out
* ok 15: [index v1] 2) create a stealth corruption in a delta base reference
* expecting success: test -f file_101_foo1 && ! cmp file_101 file_101_foo1
file_101 file_101_foo1 differ: char 5, line 2
* ok 16: [index v1] 3) corrupted delta happily returned wrong data
* expecting success: test_must_fail git fsck --full $commit
error: .git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
SHA1 checksum mismatch
error: packed 0b968294884af115eb5a1b941b3dabd48470c3bb from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
is corrupt
error: sha1 mismatch 0b968294884af115eb5a1b941b3dabd48470c3bb
error: 0b968294884af115eb5a1b941b3dabd48470c3bb: object corrupt or missing
* ok 17: [index v1] 4) confirm that the pack is actually corrupted
* expecting success: pack4=$(git pack-objects test-4 <obj-list) &&
test -f "test-4-${pack1}.pack"
* ok 18: [index v1] 5) pack-objects happily reuses corrupted data
* expecting success: test_must_fail git verify-pack -v "test-4-${pack1}.pack"
error: packed 0b968294884af115eb5a1b941b3dabd48470c3bb from
test-4-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack is corrupt
test-4-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack: bad
* ok 19: [index v1] 6) newly created pack is BAD !
* expecting success: rm -f .git/objects/pack/* &&
git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git prune-packed &&
git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
cmp "test-2-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"
pack 9108b6dfd43bf36ccbfc2839fe62d1503bf84292
test-2-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.idx
differ: char 7273, line 23
* FAIL 20: [index v2] 1) stream pack to repository
rm -f .git/objects/pack/* &&
git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git prune-packed &&
git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
cmp "test-2-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"
* expecting success: # 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
20+0 records in
20+0 records out
* ok 21: [index v2] 2) create a stealth corruption in a delta base reference
* expecting success: test -f file_101_foo2 && ! cmp file_101 file_101_foo2
file_101 file_101_foo2 differ: char 5, line 2
* ok 22: [index v2] 3) corrupted delta happily returned wrong data
* expecting success: test_must_fail git fsck --full $commit
error: .git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
SHA1 checksum mismatch
error: index CRC mismatch for object
0b968294884af115eb5a1b941b3dabd48470c3bb from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
at offset 844376
error: packed 0b968294884af115eb5a1b941b3dabd48470c3bb from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
is corrupt
error: sha1 mismatch 0b968294884af115eb5a1b941b3dabd48470c3bb
error: 0b968294884af115eb5a1b941b3dabd48470c3bb: object corrupt or missing
* ok 23: [index v2] 4) confirm that the pack is actually corrupted
* expecting success: test_must_fail git pack-objects test-5 <obj-list &&
test_must_fail git pack-objects --no-reuse-object test-6 <obj-list
error: bad packed object CRC for 0b968294884af115eb5a1b941b3dabd48470c3bb
error: bad packed object CRC for 0b968294884af115eb5a1b941b3dabd48470c3bb
error: failed to read object 0b968294884af115eb5a1b941b3dabd48470c3bb
at offset 844376 from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
fatal: object 0b968294884af115eb5a1b941b3dabd48470c3bb is corrupted
error: bad packed object CRC for 0b968294884af115eb5a1b941b3dabd48470c3bb
error: failed to read object 0b968294884af115eb5a1b941b3dabd48470c3bb
at offset 844376 from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
fatal: object 0b968294884af115eb5a1b941b3dabd48470c3bb is corrupted
* ok 24: [index v2] 5) pack-objects refuses to reuse corrupted data
* expecting 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 + $nr * 4)) &&
( while read obj
do git cat-file -p $obj >/dev/null || exit 1
done <obj-list ) &&
err=$(test_must_fail git verify-pack \
".git/objects/pack/pack-${pack1}.pack" 2>&1) &&
echo "$err" | grep "CRC mismatch"
pack 9108b6dfd43bf36ccbfc2839fe62d1503bf84292
4+0 records in
4+0 records out
error: index CRC mismatch for object
1297547aab30f952af805d38f6f1c1930cb3117b from
.git/objects/pack/pack-9108b6dfd43bf36ccbfc2839fe62d1503bf84292.pack
at offset 23376
* ok 25: [index v2] 6) verify-pack detects CRC mismatch
* expecting success:
rm -f .git/objects/pack/* &&
cp test-1-${pack1}.pack .git/objects/pack/pack-${pack1}.pack &&
(
cd .git/objects/pack
git index-pack pack-${pack1}.pack
) &&
test -f .git/objects/pack/pack-${pack1}.idx
9108b6dfd43bf36ccbfc2839fe62d1503bf84292
* ok 26: running index-pack in the object store
* failed 4 among 26 test(s)
^ permalink raw reply
* [usability bug] git branch -a does not disambiguate remote and local branches
From: Constantine Plotnikov @ 2008-12-15 18:15 UTC (permalink / raw)
To: git
Let's consider the following scenario:
mkdir bare.git
mkdir local
cd bare.git
git --bare init
cd ../local
git init
echo test > test.txt
git add test.txt
git commit -m test
git remote add origin `pwd`/../bare.git
git push --all
git checkout -b origin/master master
echo updated > test.txt
git add test.txt
git commit -m updated
Note that that in this scenario, the user has created local branch in
the folder with the same name as a remote branch. While the supposed
user here is apparently shooting itself in the foot, the scenario is
still supported by git, and might happen as a result of more logical
git operations (like git fetch).
After this scenario is executed, git branch -a will give the following output:
master
* origin/master
origin/master
Note that there is two origin/master entries, but it is not clear
which is remote is and which is the local. I think that "git branch
-a" should print unambiguous names, qualifying them if needed.
Constantine
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Brandon Casey @ 2008-12-15 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Markus Heidelberg, gitster, git
In-Reply-To: <20081214111939.GC6499@coredump.intra.peff.net>
Jeff King wrote:
> On Sun, Dec 14, 2008 at 12:17:07PM +0100, Johannes Schindelin wrote:
>
>>> Which annoyingly has no discussion about _why_ it no longer has an
>>> effect. But I suspect it has something to do with 25ee973 (gc: call
>>> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
>> Oops.
>>
>> But I thought that git gc --prune does expire _all_ dangling loose
>> objects _now_, not with --expire 2.weeks.ago.
>
> Nope, see 25ee973. You explicitly wrote:
>
> Note that this new behaviour makes "--prune" be a no-op.
>
> That being said, I think that is perhaps a reasonable thing for --prune
> to do (and I don't think there is any conflict with the name, because
> that is what it _used_ to do before becoming a no-op). But nobody has
> actually implemented it.
Maybe --mrproper would be a more appropriate name.
-brandon
^ permalink raw reply
* [PATCH 2/2] bash completion: Sync config variables with its man page
From: Lee Marlow @ 2008-12-15 17:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
In-Reply-To: <1229363149-37757-1-git-send-email-lee.marlow@gmail.com>
Add 'normal' to config color options.
Add 'mergeoptions' to branch config options.
Add 'proxy' and 'mirror' to remote config options.
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 87 +++++++++++++++++++++++++++++---
1 files changed, 80 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 79cbed5..e004549 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1155,7 +1155,7 @@ _git_config ()
;;
color.*.*)
__gitcomp "
- black red green yellow blue magenta cyan white
+ normal black red green yellow blue magenta cyan white
bold dim ul blink reverse
"
return
@@ -1179,7 +1179,7 @@ _git_config ()
branch.*.*)
local pfx="${cur%.*}."
cur="${cur##*.}"
- __gitcomp "remote merge" "$pfx" "$cur"
+ __gitcomp "remote merge mergeoptions" "$pfx" "$cur"
return
;;
branch.*)
@@ -1192,7 +1192,7 @@ _git_config ()
local pfx="${cur%.*}."
cur="${cur##*.}"
__gitcomp "
- url fetch push skipDefaultUpdate
+ url proxy fetch push mirror skipDefaultUpdate
receivepack uploadpack tagopt
" "$pfx" "$cur"
return
@@ -1206,6 +1206,8 @@ _git_config ()
esac
__gitcomp "
apply.whitespace
+ branch.autosetupmerge
+ branch.autosetuprebase
clean.requireForce
color.branch
color.branch.current
@@ -1220,46 +1222,95 @@ _git_config ()
color.diff.old
color.diff.plain
color.diff.whitespace
+ color.interactive
+ color.interactive.header
+ color.interactive.help
+ color.interactive.prompt
color.pager
color.status
color.status.added
color.status.changed
color.status.header
+ color.status.nobranch
color.status.untracked
+ color.status.updated
+ color.ui
+ commit.template
+ core.autocrlf
+ core.bare
core.compression
+ core.deltaBaseCacheLimit
+ core.editor
+ core.excludesfile
core.fileMode
+ core.fsyncobjectfiles
core.gitProxy
+ core.ignoreCygwinFSTricks
core.ignoreStat
core.logAllRefUpdates
core.loosecompression
core.packedGitLimit
core.packedGitWindowSize
+ core.pager
core.preferSymlinkRefs
+ core.preloadindex
+ core.quotepath
core.repositoryFormatVersion
+ core.safecrlf
core.sharedRepository
+ core.symlinks
+ core.trustctime
core.warnAmbiguousRefs
+ core.whitespace
+ core.worktree
+ diff.autorefreshindex
+ diff.external
+ diff.mnemonicprefix
diff.renameLimit
+ diff.renameLimit.
diff.renames
fetch.unpackLimit
format.headers
- format.subjectprefix
+ format.numbered
+ format.pretty
+ format.suffix
+ gc.aggressiveWindow
+ gc.auto
+ gc.autopacklimit
gc.packrefs
+ gc.pruneexpire
gc.reflogexpire
gc.reflogexpireunreachable
gc.rerereresolved
gc.rerereunresolved
gitcvs.allbinary
+ gitcvs.dbTableNamePrefix
gitcvs.dbdriver
gitcvs.dbname
gitcvs.dbpass
- gitcvs.dbtablenameprefix
gitcvs.dbuser
gitcvs.enabled
gitcvs.logfile
+ gitcvs.usecrlfattr
+ gui.blamehistoryctx
+ gui.commitmsgwidth
+ gui.copyblamethreshold
+ gui.diffcontext
+ gui.encoding
+ gui.fastcopyblame
+ gui.matchtrackingbranch
+ gui.newbranchtemplate
+ gui.pruneduringfetch
+ gui.spellingdictionary
+ gui.trustmtime
+ help.autocorrect
+ help.browser
+ help.format
http.lowSpeedLimit
http.lowSpeedTime
http.maxRequests
http.noEPSV
+ http.proxy
http.sslCAInfo
http.sslCAPath
http.sslCert
@@ -1267,27 +1318,49 @@ _git_config ()
http.sslVerify
i18n.commitEncoding
i18n.logOutputEncoding
+ instaweb.browser
+ instaweb.httpd
+ instaweb.local
+ instaweb.modulepath
+ instaweb.port
+ log.date
log.showroot
- merge.summary
+ man.viewer
+ merge.conflictstyle
+ merge.log
+ merge.renameLimit
+ merge.stat
merge.tool
merge.verbosity
+ mergetool.keepBackup
pack.compression
pack.deltaCacheLimit
pack.deltaCacheSize
pack.depth
+ pack.indexVersion
+ pack.packSizeLimit
+ pack.threads
pack.window
pack.windowMemory
pull.octopus
pull.twohead
+ receive.denyCurrentBranch
+ receive.denyDeletes
receive.denyNonFastForwards
+ receive.fsckObjects
receive.unpackLimit
- repack.useDeltaBaseOffset
+ repack.usedeltabaseoffset
+ rerere.autoupdate
+ rerere.enabled
showbranch.default
+ status.relativePaths
+ status.showUntrackedFiles
tar.umask
transfer.unpackLimit
user.email
user.name
user.signingkey
+ web.browser
branch. remote.
"
}
--
1.6.1.rc2.20.gde0d
^ permalink raw reply related
* [PATCH 1/2] bash completion: Sort config completion variables
From: Lee Marlow @ 2008-12-15 17:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Sort the config variables to make sync-ing them with
Documents/config.txt easier in the future.
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 77 ++++++++++++++++---------------
1 files changed, 40 insertions(+), 37 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c79c98f..79cbed5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1206,84 +1206,87 @@ _git_config ()
esac
__gitcomp "
apply.whitespace
- core.fileMode
- core.gitProxy
- core.ignoreStat
- core.preferSymlinkRefs
- core.logAllRefUpdates
- core.loosecompression
- core.repositoryFormatVersion
- core.sharedRepository
- core.warnAmbiguousRefs
- core.compression
- core.packedGitWindowSize
- core.packedGitLimit
clean.requireForce
color.branch
color.branch.current
color.branch.local
- color.branch.remote
color.branch.plain
+ color.branch.remote
color.diff
- color.diff.plain
- color.diff.meta
+ color.diff.commit
color.diff.frag
- color.diff.old
+ color.diff.meta
color.diff.new
- color.diff.commit
+ color.diff.old
+ color.diff.plain
color.diff.whitespace
color.pager
color.status
- color.status.header
color.status.added
color.status.changed
+ color.status.header
color.status.untracked
+ core.compression
+ core.fileMode
+ core.gitProxy
+ core.ignoreStat
+ core.logAllRefUpdates
+ core.loosecompression
+ core.packedGitLimit
+ core.packedGitWindowSize
+ core.preferSymlinkRefs
+ core.repositoryFormatVersion
+ core.sharedRepository
+ core.warnAmbiguousRefs
diff.renameLimit
diff.renames
fetch.unpackLimit
format.headers
format.subjectprefix
- gitcvs.enabled
- gitcvs.logfile
- gitcvs.allbinary
- gitcvs.dbname gitcvs.dbdriver gitcvs.dbuser gitcvs.dbpass
- gitcvs.dbtablenameprefix
gc.packrefs
gc.reflogexpire
gc.reflogexpireunreachable
gc.rerereresolved
gc.rerereunresolved
- http.sslVerify
- http.sslCert
- http.sslKey
- http.sslCAInfo
- http.sslCAPath
- http.maxRequests
+ gitcvs.allbinary
+ gitcvs.dbdriver
+ gitcvs.dbname
+ gitcvs.dbpass
+ gitcvs.dbtablenameprefix
+ gitcvs.dbuser
+ gitcvs.enabled
+ gitcvs.logfile
http.lowSpeedLimit
http.lowSpeedTime
+ http.maxRequests
http.noEPSV
+ http.sslCAInfo
+ http.sslCAPath
+ http.sslCert
+ http.sslKey
+ http.sslVerify
i18n.commitEncoding
i18n.logOutputEncoding
log.showroot
- merge.tool
merge.summary
+ merge.tool
merge.verbosity
- pack.window
- pack.depth
- pack.windowMemory
pack.compression
- pack.deltaCacheSize
pack.deltaCacheLimit
+ pack.deltaCacheSize
+ pack.depth
+ pack.window
+ pack.windowMemory
pull.octopus
pull.twohead
+ receive.denyNonFastForwards
+ receive.unpackLimit
repack.useDeltaBaseOffset
showbranch.default
tar.umask
transfer.unpackLimit
- receive.unpackLimit
- receive.denyNonFastForwards
- user.name
user.email
+ user.name
user.signingkey
branch. remote.
"
--
1.6.1.rc2.20.gde0d
^ permalink raw reply related
* Re: [PATCH v3] <-- really v4
From: Marcel M. Cary @ 2008-12-15 17:38 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt
In-Reply-To: <1229362477-22538-1-git-send-email-marcel@oak.homeunix.org>
I guess I'm really on v4, sorry.
Marcel
^ permalink raw reply
* [PATCH] objects to be pruned immediately don't have to be loosened
From: Nicolas Pitre @ 2008-12-15 17:38 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3331 bytes --]
When there is no grace period before pruning unreferenced objects, it is
pointless to push those objects in their loose form just to delete them
right away.
Also be more explicit about the possibility of using "now" in the
gc.pruneexpire config variable (needed for the above behavior to
happen).
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Mon, 15 Dec 2008, Theodore Tso wrote:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
> > so that git prune can drop them. And git gc invokes git prune so that
> > only unreachable objects older than 2 weeks are dropped.
>
> To be even more explicit, "git gc" will **unpack** objects that have
> become unreachable and were currently in packs. As a result, the
> amount of disk space used by a git repository can actually go **up**
> dramatically after a "git gc" operation, which could be surprising for
> someone who is running close to full on their filesystem, deletes a
> number of branches from a tracking repository, and then does a "git
> gc" may get a very unpleasant surprise.
>
> A really good repository which shows this is linux-next, since it is
> constantly getting rewound, and old branches are reserved via a tag
> such as next-20081204. If you update the your local copy of the
> linux-next repository every day, you will accumulate a large number of
> these old branch tags. If you then delete a whole series of them, and
> run git-gc, the operation will take quite a while, and the number of
> blocks and inodes used will grow significantly. They will disappear
> after a "git prune", but when I do this housekeeping operation, I've
> often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
> just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
> option to "git gc".
What about this?
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 21ea165..ca45e71 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -702,7 +702,9 @@ gc.packrefs::
gc.pruneexpire::
When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
- Override the grace period with this config variable.
+ Override the grace period with this config variable. The value
+ "now" may be used to disable this grace period and always prune
+ unreachable objects immediately.
gc.reflogexpire::
'git-reflog expire' removes reflog entries older than
diff --git a/builtin-gc.c b/builtin-gc.c
index 781df60..f8eae4a 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -188,7 +188,9 @@ static int need_to_gc(void)
* there is no need.
*/
if (too_many_packs())
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
else if (!too_many_loose_objects())
return 0;
@@ -243,7 +245,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
"run \"git gc\" manually. See "
"\"git help gc\" for more information.\n");
} else
- append_option(argv_repack, "-A", MAX_ADD);
+ append_option(argv_repack,
+ !strcmp(prune_expire, "now") ? "-a" : "-A",
+ MAX_ADD);
if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))
return error(FAILED_RUN, argv_pack_refs[0]);
^ permalink raw reply related
* [PATCH v3] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-12-15 17:34 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <7v4p174diu.fsf@gitster.siamese.dyndns.org>
I want directories of my working tree to be linked to from various
paths on my filesystem where third-party components expect them, both
in development and production environments. A build system's install
step could solve this, but I develop scripts and web pages that don't
need to be built. Git's submodule system could solve this, but we
tend to develop, branch, and test those directories all in unison, so
one big repository feels more natural. We prefer to edit and commit
on the symlinked paths, not the canonical ones, and in that setting,
"git pull" fails to find the top-level directory of the repository
while other commands work fine.
"git pull" fails because POSIX shells have a notion of current working
directory that is different from getcwd(). The shell stores this path
in PWD. As a result, "cd ../" can be interpreted differently in a
shell script than chdir("../") in a C program. The shell interprets
"../" by essentially stripping the last textual path component from
PWD, whereas C chdir() follows the ".." link in the current directory
on the filesystem. When PWD is a symlink, these are different
destinations. As a result, Git's C commands find the correct
top-level working tree, and shell scripts do not.
Changes:
* When interpreting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus contrasting scenarios
that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
> > I also removed the "pwd -P" from the unit test.
>
> Hmm, really...?
Ouch. Removing just one occurrence won't help much, will it.
> > Do you think these test cases should run all the time here?
>
> I'd say so. Your supporting argument could be "See, push works just
> fine with this layout, but pull doesn't because it is a shell script
> that can be fooled, and this change is to fix the inconsistencies
> between them."
Ok, removed those cases from test_debug and emphasized in the first
paragraph of the commit message that other commands support this kind
of "sideways jumping."
> But whether it is inside test_debug or not, the test should check
> not just the exit status from 'git push' but also check what
> happened to the receiving repository at least to make sure it is
> pushing to the location you are expecting it to.
Ok, I did this by adding an additional file each time and checking the
same path in the other repository.
git-sh-setup.sh | 23 ++++++++++++-
t/t2300-cd-to-toplevel.sh | 37 +++++++++++++++++++++
t/t5521-pull-symlink.sh | 78 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 136 insertions(+), 2 deletions(-)
create mode 100755 t/t2300-cd-to-toplevel.sh
create mode 100755 t/t5521-pull-symlink.sh
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..f07d96b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,8 +85,27 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
- cd "$cdup" || {
- echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
+ case "$cdup" in
+ /*)
+ # Not quite the same as if we did "cd -P '$cdup'" when
+ # $cdup contains ".." after symlink path components.
+ # Don't fix that case at least until Git switches to
+ # "cd -P" across the board.
+ phys="$cdup"
+ ;;
+ ..|../*|*/..|*/../*)
+ # Interpret $cdup relative to the physical, not logical, cwd.
+ # Probably /bin/pwd is more portable than passing -P to cd or pwd.
+ phys="$(/bin/pwd)/$cdup"
+ ;;
+ *)
+ # There's no "..", so no need to make things absolute.
+ phys="$cdup"
+ ;;
+ esac
+
+ cd "$phys" || {
+ echo >&2 "Cannot chdir to $phys, the toplevel of the working tree"
exit 1
}
fi
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
new file mode 100755
index 0000000..beddb4e
--- /dev/null
+++ b/t/t2300-cd-to-toplevel.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='cd_to_toplevel'
+
+. ./test-lib.sh
+
+test_cd_to_toplevel () {
+ test_expect_success "$2" '
+ (
+ cd '"'$1'"' &&
+ . git-sh-setup &&
+ cd_to_toplevel &&
+ [ "$(/bin/pwd)" = "$TOPLEVEL" ]
+ )
+ '
+}
+
+TOPLEVEL="$(/bin/pwd)/repo"
+mkdir -p repo/sub/dir
+mv .git repo/
+SUBDIRECTORY_OK=1
+
+test_cd_to_toplevel repo 'at physical root'
+
+test_cd_to_toplevel repo/sub/dir 'at physical subdir'
+
+ln -s repo symrepo
+test_cd_to_toplevel symrepo 'at symbolic root'
+
+ln -s repo/sub/dir subdir-link
+test_cd_to_toplevel subdir-link 'at symbolic subdir'
+
+cd repo
+ln -s sub/dir internal-link
+test_cd_to_toplevel internal-link 'at internal symbolic subdir'
+
+test_done
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100755
index 0000000..5672b51
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+
+mkdir subdir
+echo file >subdir/file
+git add subdir/file
+git commit -q -m file
+git clone -q . clone-repo
+ln -s clone-repo/subdir/ subdir-link
+
+
+# Demonstrate that things work if we just avoid the symlink
+#
+test_expect_success 'pulling from real subdir' '
+ (
+ echo real >subdir/file &&
+ git commit -m real subdir/file &&
+ cd clone-repo/subdir/ &&
+ git pull &&
+ test real = $(cat file)
+ )
+'
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# because git would find the .git/config for the "trash directory"
+# repo, not for the clone-repo repo. The "trash directory" repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. A POSIX shell's "cd" works a little differently
+# than chdir() in C; "cd -P" is much closer to chdir().
+#
+test_expect_success 'pulling from symlinked subdir' '
+ (
+ echo link >subdir/file &&
+ git commit -m link subdir/file &&
+ cd subdir-link/ &&
+ git pull &&
+ test link = $(cat file)
+ )
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context. It's just that "git pull" breaks.
+#
+test_expect_success 'pushing from symlinked subdir' '
+ (
+ cd subdir-link/ &&
+ echo push >file &&
+ git commit -m push ./file &&
+ git push
+ ) &&
+ test push = $(git show HEAD:subdir/file)
+'
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH v2] git-branch: display sha1 on branch deletion
From: Brandon Casey @ 2008-12-15 17:23 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20081213063104.GA8480@coredump.intra.peff.net>
Jeff King wrote:
> 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).
Yeah I was counting on the smallness of that chance to let me be lazy and
not think about how to get the proper abbreviated sha1.
> 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).
My feelings won't be hurt if you want to change it.
-brandon
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Brandon Casey @ 2008-12-15 17:11 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
Theodore Tso wrote:
> I've
> often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
> just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
> option to "git gc".
repack -a -d -l
Notice the lowercase 'a'.
git-gc calls repack with uppercase 'A' which is what causes the unreachable
objects to be unpacked. Little 'a', is for people who know what they are
doing, and want git to just drop unreachable objects.
-brandon
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Jakub Narebski @ 2008-12-15 17:07 UTC (permalink / raw)
To: Theodore Tso; +Cc: Björn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
> > so that git prune can drop them. And git gc invokes git prune so that
> > only unreachable objects older than 2 weeks are dropped.
>
> To be even more explicit, "git gc" will **unpack** objects that have
> become unreachable and were currently in packs. As a result, the
> amount of disk space used by a git repository can actually go **up**
> dramatically after a "git gc" operation, which could be surprising for
> someone who is running close to full on their filesystem, deletes a
> number of branches from a tracking repository, and then does a "git
> gc" may get a very unpleasant surprise.
>
> A really good repository which shows this is linux-next, since it is
> constantly getting rewound, and old branches are reserved via a tag
> such as next-20081204. If you update the your local copy of the
> linux-next repository every day, you will accumulate a large number of
> these old branch tags. If you then delete a whole series of them, and
> run git-gc, the operation will take quite a while, and the number of
> blocks and inodes used will grow significantly. They will disappear
> after a "git prune", but when I do this housekeeping operation, I've
> often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
> just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
> option to "git gc".
There was an idea to have "git gc --prune" run "git prune"
unconditionally, i.e. without grace period for dangling loose objects.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: hooks/post-update execs git-update-server-info
From: Jakub Narebski @ 2008-12-15 17:06 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <gi600m$tts$2@ger.gmane.org>
Sitaram Chamarty <sitaramc@gmail.com> writes:
> shouldn't .git/hooks/post-update contain "exec git
> update-server-info" (note the space not hyphen) instead of
> "exec git-update-server-info"?
>
> Either I am horribly confused or HTTP pulls have not been
> working on post 1.6 gits and no one has noticed till now :-)
If I understand correctly hooks run with GIT_EXEC_PATH prepended to
PATH, so everything should work; and it has to work to not force users
to upgrade their (perhaps customized) hooks after upgrading git.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Johan Herland @ 2008-12-15 16:59 UTC (permalink / raw)
To: git
Cc: Mark Brown, Theodore Tso, Bj?rn Steinbrink, Mikael Magnusson,
Bruce Stephens
In-Reply-To: <20081215161212.GE31145@sirena.org.uk>
On Monday 15 December 2008, Mark Brown wrote:
> On Mon, Dec 15, 2008 at 10:56:10AM -0500, Theodore Tso wrote:
> > On Mon, Dec 15, 2008 at 03:08:34PM +0100, Bj?rn Steinbrink wrote:
> > > To clarify that a bit more: git gc keeps unreachable objects
> > > unpacked, so that git prune can drop them. And git gc invokes git
> > > prune so that only unreachable objects older than 2 weeks are
> > > dropped.
> >
> > To be even more explicit, "git gc" will **unpack** objects that
> > have become unreachable and were currently in packs. As a result,
> > the amount of disk space used by a git repository can actually go
> > **up** dramatically after a "git gc" operation, which could be
> > surprising for someone who is running close to full on their
> > filesystem, deletes a number of branches from a tracking
> > repository, and then does a "git gc" may get a very unpleasant
> > surprise.
>
> It can also cause things like the "please repack" warning in git gui
> to go off. This is especially unhelpful since they tend to tell you
> to go and do a gc to resolve the problem.
Instead of exploding all unreachable objects into loose objects, does it
make sense to repack them into a separate pack? AFAICS, that would
solve both the disk usage problem and the git-gui-"please repack"
problem. Also, it might make git-prune's job much easier, since
unreachable objects are now located in a single pack only?
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Mikael Magnusson @ 2008-12-15 16:59 UTC (permalink / raw)
To: Mark Brown; +Cc: Theodore Tso, Bj?rn Steinbrink, Bruce Stephens, git
In-Reply-To: <20081215161212.GE31145@sirena.org.uk>
2008/12/15 Mark Brown <broonie@sirena.org.uk>:
> On Mon, Dec 15, 2008 at 10:56:10AM -0500, Theodore Tso wrote:
>> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Bj?rn Steinbrink wrote:
>
>> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
>> > so that git prune can drop them. And git gc invokes git prune so that
>> > only unreachable objects older than 2 weeks are dropped.
>
>> To be even more explicit, "git gc" will **unpack** objects that have
>> become unreachable and were currently in packs. As a result, the
>> amount of disk space used by a git repository can actually go **up**
>> dramatically after a "git gc" operation, which could be surprising for
>> someone who is running close to full on their filesystem, deletes a
>> number of branches from a tracking repository, and then does a "git
>> gc" may get a very unpleasant surprise.
>
> It can also cause things like the "please repack" warning in git gui to
> go off. This is especially unhelpful since they tend to tell you to go
> and do a gc to resolve the problem.
A thought that occurs to me is to add some sort of flag to git count-objects
that prints the number of objects older than some interval in a separate field.
That way git gui would give less (maybe no) false alarms.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH] bash completion: remove deprecated --prune from git-gc
From: Brandon Casey @ 2008-12-15 16:51 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Markus Heidelberg, gitster, git
In-Reply-To: <20081214111213.GA6499@coredump.intra.peff.net>
Jeff King wrote:
> On Sun, Dec 14, 2008 at 11:38:17AM +0100, Johannes Schindelin wrote:
>
>>> - __gitcomp "--prune --aggressive"
>>> + __gitcomp "--aggressive"
>> git gc --prune is deprecated? That's news to me.
>
> Check out 9e7d501 (builtin-gc.c: deprecate --prune, it now really has no
> effect, 2008-05-09).
>
> Which annoyingly has no discussion about _why_ it no longer has an
> effect. But I suspect it has something to do with 25ee973 (gc: call
> "prune --expire 2.weeks.ago" by default, 2008-03-12) by you.
I think the nail in the coffin for --prune was a37cce3b, which preceded
9e7d501. I guess the commit message for 9e7d501 made sense with a37cce3b
as a reference. There was another commit around the same time which
claimed that --prune was deprecated even though it still provided some
functionality, hence the "...really has no effect" part.
I definitely remember that Johannes implemented the gc.pruneExpire
functionality, so his "That's news to me" made me laugh. Thanks for
the chuckle Johannes. :)
-brandon
^ permalink raw reply
* Re: Interactive rebase encoding
From: Johannes Schindelin @ 2008-12-15 16:56 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812150821g4a032af0u31425fd7f4c0fd9@mail.gmail.com>
Hi,
On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
> On Mon, Dec 15, 2008 at 6:54 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > Indeed, I cannot think of any scenario where it might make sense to
> > have a different encoding in git rebase -i than in git log.
>
> For IDE, it might make sense to force UTF-8 encoding instead of using
> currently configured logoutputencoding.
I consider rebase -i to be porcelain, and as such not suitable to be used
as a backend for an IDE. Help the git-sequencer effort if you want a
plumbing.
Ciao,
Dscho
^ permalink raw reply
* [Q] Interactive rebase and editor failure
From: Constantine Plotnikov @ 2008-12-15 16:37 UTC (permalink / raw)
To: git
The git rebase -i detects situation if the editor exits with non-zero
exit code and displays error in such case.
However in this case for some reason, the rebase operation is not
aborted. What is the reason behind this logic? Is it the bug or
feature?
Constantine
^ permalink raw reply
* Re: Interactive rebase encoding
From: Constantine Plotnikov @ 2008-12-15 16:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0812151652400.30769@pacific.mpi-cbg.de>
On Mon, Dec 15, 2008 at 6:54 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
>
>> The interactive rebase command builds a text file and passes it to
>> editor specified as environment variable or as configuration parameter.
>> However the man page for rebase operation says nothing about which
>> encoding will be used for that file. Apparently i18n.logoutputencoding
>> is used.
>
> As rebase -i does nothing else than piping the output of git log into a
> file (at least this is the first step), I thought it would be obvious that
> it uses the output encoding preferred by the user.
Yes. That was my first hypothesis, but I had to check it through small
experiment and source code examination. And if consider the bug
described in the thread
http://kerneltrap.org/mailarchive/git/2008/11/11/4063184, the
hypothesis might have been incorrect.
>
> Indeed, I cannot think of any scenario where it might make sense to have a
> different encoding in git rebase -i than in git log.
>
For IDE, it might make sense to force UTF-8 encoding instead of using
currently configured logoutputencoding. Currently the extra call to
git config is needed to check expected encoding of the file before
data could be shown to the user. Also user specified encoding might
fail to display some characters in commit messages that was encoded
using other encodings, forcing UTF-8 would have also fixed this
problem as well.
BTW for IDEs an option that causes non-abbreviated commit hashes would
have been useful as well.
Constantine
^ permalink raw reply
* [TortoiseGit]: Anyone seen this challenge?
From: Tim Visher @ 2008-12-15 16:20 UTC (permalink / raw)
To: git
Anyone aware of this challenge?
http://github.com/blog/256-tortoisegit-challenge
They've noted the existence of the google code project.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* hooks/post-update execs git-update-server-info
From: Sitaram Chamarty @ 2008-12-15 16:18 UTC (permalink / raw)
To: git
shouldn't .git/hooks/post-update contain "exec git
update-server-info" (note the space not hyphen) instead of
"exec git-update-server-info"?
Either I am horribly confused or HTTP pulls have not been
working on post 1.6 gits and no one has noticed till now :-)
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Mark Brown @ 2008-12-15 16:12 UTC (permalink / raw)
To: Theodore Tso; +Cc: Bj?rn Steinbrink, Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215155610.GA11502@mit.edu>
On Mon, Dec 15, 2008 at 10:56:10AM -0500, Theodore Tso wrote:
> On Mon, Dec 15, 2008 at 03:08:34PM +0100, Bj?rn Steinbrink wrote:
> > To clarify that a bit more: git gc keeps unreachable objects unpacked,
> > so that git prune can drop them. And git gc invokes git prune so that
> > only unreachable objects older than 2 weeks are dropped.
> To be even more explicit, "git gc" will **unpack** objects that have
> become unreachable and were currently in packs. As a result, the
> amount of disk space used by a git repository can actually go **up**
> dramatically after a "git gc" operation, which could be surprising for
> someone who is running close to full on their filesystem, deletes a
> number of branches from a tracking repository, and then does a "git
> gc" may get a very unpleasant surprise.
It can also cause things like the "please repack" warning in git gui to
go off. This is especially unhelpful since they tend to tell you to go
and do a gc to resolve the problem.
^ permalink raw reply
* Re: "git gc" doesn't seem to remove loose objects any more
From: Theodore Tso @ 2008-12-15 15:56 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Mikael Magnusson, Bruce Stephens, git
In-Reply-To: <20081215140834.GA3684@atjola.homenet>
On Mon, Dec 15, 2008 at 03:08:34PM +0100, Björn Steinbrink wrote:
> To clarify that a bit more: git gc keeps unreachable objects unpacked,
> so that git prune can drop them. And git gc invokes git prune so that
> only unreachable objects older than 2 weeks are dropped.
To be even more explicit, "git gc" will **unpack** objects that have
become unreachable and were currently in packs. As a result, the
amount of disk space used by a git repository can actually go **up**
dramatically after a "git gc" operation, which could be surprising for
someone who is running close to full on their filesystem, deletes a
number of branches from a tracking repository, and then does a "git
gc" may get a very unpleasant surprise.
A really good repository which shows this is linux-next, since it is
constantly getting rewound, and old branches are reserved via a tag
such as next-20081204. If you update the your local copy of the
linux-next repository every day, you will accumulate a large number of
these old branch tags. If you then delete a whole series of them, and
run git-gc, the operation will take quite a while, and the number of
blocks and inodes used will grow significantly. They will disappear
after a "git prune", but when I do this housekeeping operation, I've
often wished for a --yes-I-know-what-I-am-doing-and-it's-unsafe-but-
just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
option to "git gc".
- Ted
^ permalink raw reply
* Re: Interactive rebase encoding
From: Johannes Schindelin @ 2008-12-15 15:54 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812150442n48609eadl4f3e47fcc715e643@mail.gmail.com>
Hi,
On Mon, 15 Dec 2008, Constantine Plotnikov wrote:
> The interactive rebase command builds a text file and passes it to
> editor specified as environment variable or as configuration parameter.
> However the man page for rebase operation says nothing about which
> encoding will be used for that file. Apparently i18n.logoutputencoding
> is used.
As rebase -i does nothing else than piping the output of git log into a
file (at least this is the first step), I thought it would be obvious that
it uses the output encoding preferred by the user.
Indeed, I cannot think of any scenario where it might make sense to have a
different encoding in git rebase -i than in git log.
Ciao,
Dscho
^ permalink raw reply
* Re: Interactive rebase encoding
From: Miklos Vajna @ 2008-12-15 15:13 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812150442n48609eadl4f3e47fcc715e643@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
On Mon, Dec 15, 2008 at 03:42:08PM +0300, Constantine Plotnikov <constantine.plotnikov@gmail.com> wrote:
> The interactive rebase command builds a text file and passes it to
> editor specified as environment variable or as configuration
> parameter. However the man page for rebase operation says nothing
> about which encoding will be used for that file. Apparently
> i18n.logoutputencoding is used. I think that the man page for rebase
> operation should explicitly specify it.
Care to send a patch?
> Also it might make sense to use explicit encoding parameter for
> interactive rebase operation.
Do you have a use-case where having a different encoding for log output
and rebase -i todo list makes sense?
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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