* Re: git-format-patch possible regressions
From: Johannes Schindelin @ 2006-05-25 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git, Linus Torvalds
In-Reply-To: <7vy7wpr97n.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 25 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Thinking about this again, it makes more sense not to imply --numbered:
>
> Yes, that makes sense. That way you can say "Please start
> naming the output files at 0032-xxxx.txt, because you gave me 31
> patch series last time, but I do not want [PATCH x/y] on the
> subject line, just [PATCH]".
>
> That brings up another issue. Don't we need to have another
> option --total-number that overrides the /y part above?
I thought about that, too. Isn't the --numbered only useful for submitting
a patch series via mail? And isn't it necessary to make certain that these
patches really apply in that order? Isn't it then sensible to force the
user to have a branch (at least a throw-away one) having exactly these
patches, just to make sure that the patches really, really apply in that
order?
If all that is true, then --start-number && --numbered does not make sense
at all.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add instructions to commit template.
From: Martin Waitz @ 2006-05-25 23:42 UTC (permalink / raw)
To: git
New users can be irritated by the git status text in their editor.
Let's give them a short help.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
git-commit.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 6785826..1983d45 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -626,6 +626,9 @@ fi
if test -z "$no_edit"
then
{
+ echo ""
+ echo "# Please enter the commit message for your changes."
+ echo "# (Comment lines starting with '#' will not be included)"
test -z "$only_include_assumed" || echo "$only_include_assumed"
run_status
} >>"$GIT_DIR"/COMMIT_EDITMSG
--
1.3.3.gc6dc-dirty
--
Martin Waitz
^ permalink raw reply related
* t8001-annotate.sh fails on Mac OS X
From: Stefan Pfetzing @ 2006-05-25 23:53 UTC (permalink / raw)
To: Git Mailing List
Hi,
for some reason I could not yet figure out, t8001-annotate.sh fails at test 18.
--- snip ---
* ok 17: some edit
* expecting success: check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
Author A (expected 1, attributed 1) good
Author B1 (expected 1, attributed 1) good
Author D (expected 1, attributed 2) bad
Author A U Thor (expected 1, attributed 1) good
Author B2 (expected 1, attributed 1) good
Author B (expected 1, attributed 1) good
* FAIL 18: some edit
check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
* failed 1 among 18 test(s)
--- snap ---
And git-annotate in the trash dir produces the following:
--- snip ---
5c085656 ( A 2006-05-25 23:13:26 +0000 1)lazy dog
3f3e26a3 ( B2 2006-05-25 23:13:29 +0000 2)4A
quick brown lazy dog fox jumps over the
3b509ebb ( B 2006-05-25 23:13:27 +0000 3)lazy dog
669d4e82 ( D 2006-05-25 23:13:35 +0000 4)99
slow green fox jumps into the
f96b8861 ( B1 2006-05-25 23:13:28 +0000 5)well.
a7bad43f ( A U Thor 2006-05-25 23:13:31 +0000 6)evil merge.
669d4e82 ( D 2006-05-25 23:13:35 +0000 7)incomplete
--- snap ---
The strange point is, git log is completely ok:
--- snip ---
commit 90ef4f653d6dc33d90ce826303563e5506d5ad31
Author: C <author@example.com>
Date: Thu May 25 23:13:34 2006 +0000
Incomplete
--- snap ---
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Martin Langhoff @ 2006-05-26 0:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Git Mailing List, Junio C Hamano,
Johannes.Schindelin, spyderous, smurf
In-Reply-To: <Pine.LNX.4.64.0605221926270.3697@g5.osdl.org>
On 5/23/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> This stupid patch on top of yours seems to make git happier. It's
> disgusting, I know, but it just repacks things every kilo-commit.
Call me slow, but I am still running and rerunning that gentoo import. ;-)
The current import has reached ~200K commits, and .git is 450MB, while
the checked out tree is 230MB (680MB with .git). At this stage, git
repack -a -d is too memory hungry. I just had to kill it after it took
2GB and was still growing fast. So I have dropped the -a in my test
import for the time being.
Other than that, we are doing ~6K commits per hour on a 2GB 2GHz Opteron.
cheers,
martin
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Shawn Pearce @ 2006-05-26 1:11 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: Git Mailing List
In-Reply-To: <f3d7535d0605251653m15db34f3j46403f4ed0c4c69f@mail.gmail.com>
Stefan Pfetzing <stefan.pfetzing@gmail.com> wrote:
> Hi,
>
> for some reason I could not yet figure out, t8001-annotate.sh fails at test
> 18.
>
> --- snip ---
> * ok 17: some edit
> * expecting success: check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
> Author A (expected 1, attributed 1) good
> Author B1 (expected 1, attributed 1) good
> Author D (expected 1, attributed 2) bad
> Author A U Thor (expected 1, attributed 1) good
> Author B2 (expected 1, attributed 1) good
> Author B (expected 1, attributed 1) good
> * FAIL 18: some edit
> check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
> * failed 1 among 18 test(s)
I've been seeing the same failed test case for a long time now on
my own Mac OS X system. I think it has to do with the "git blame"
vs. "git annotate" war which never really happened.
I think we had hoped that one of the two tools would prove to be
_the_ annotation/blame tool and would get used but thus far that
hasn't happened. Since they are two different implementations
they also differ slightly over how they attribute a change across
a merge, and in this case annotate is producing a different result
from blame - but that different result isn't considered to be wrong
so it hasn't been changed in annotate. Meanwhile the test has stayed
broken as a reminder that these two generate different results.
--
Shawn.
^ permalink raw reply
* [PATCH 1/4] t3300-funny-names: shell portability fixes
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <1148609178788-git-send-email-normalperson@yhbt.net>
echo isn't remotely standardized for handling backslashes,
so cat + heredoc seems better
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t3300-funny-names.sh | 51 +++++++++++++++++++++++++++++++-----------------
1 files changed, 33 insertions(+), 18 deletions(-)
6b5ef54aa860b557f88084c1d642a611f7abcf4d
diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index 72a93da..c12270e 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -40,9 +40,11 @@ test_expect_success 'git-ls-files no-fun
t0=`git-write-tree`
echo "$t0" >t0
-echo 'just space
+cat > expected <<\EOF
+just space
no-funny
-"tabs\t,\" (dq) and spaces"' >expected
+"tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-ls-files with-funny' \
'git-update-index --add "$p1" &&
git-ls-files >current &&
@@ -58,14 +60,18 @@ test_expect_success 'git-ls-files -z wit
t1=`git-write-tree`
echo "$t1" >t1
-echo 'just space
+cat > expected <<\EOF
+just space
no-funny
-"tabs\t,\" (dq) and spaces"' >expected
+"tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-ls-tree with funny' \
'git-ls-tree -r $t1 | sed -e "s/^[^ ]* //" >current &&
diff -u expected current'
-echo 'A "tabs\t,\" (dq) and spaces"' >expected
+cat > expected <<\EOF
+A "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-index with-funny' \
'git-diff-index --name-status $t0 >current &&
diff -u expected current'
@@ -84,53 +90,62 @@ test_expect_success 'git-diff-tree -z wi
'git-diff-tree -z --name-status $t0 $t1 | tr \\0 \\012 >current &&
diff -u expected current'
-echo 'CNUM no-funny "tabs\t,\" (dq) and spaces"' >expected
+cat > expected <<\EOF
+CNUM no-funny "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree -C with-funny' \
'git-diff-tree -C --find-copies-harder --name-status \
$t0 $t1 | sed -e 's/^C[0-9]*/CNUM/' >current &&
diff -u expected current'
-echo 'RNUM no-funny "tabs\t,\" (dq) and spaces"' >expected
+cat > expected <<\EOF
+RNUM no-funny "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree delete with-funny' \
'git-update-index --force-remove "$p0" &&
git-diff-index -M --name-status \
$t0 | sed -e 's/^R[0-9]*/RNUM/' >current &&
diff -u expected current'
-echo 'diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
+cat > expected <<\EOF
+diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
similarity index NUM%
rename from no-funny
-rename to "tabs\t,\" (dq) and spaces"' >expected
-
+rename to "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree delete with-funny' \
'git-diff-index -M -p $t0 |
sed -e "s/index [0-9]*%/index NUM%/" >current &&
diff -u expected current'
chmod +x "$p1"
-echo 'diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
+cat > expected <<\EOF
+diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
old mode 100644
new mode 100755
similarity index NUM%
rename from no-funny
-rename to "tabs\t,\" (dq) and spaces"' >expected
-
+rename to "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree delete with-funny' \
'git-diff-index -M -p $t0 |
sed -e "s/index [0-9]*%/index NUM%/" >current &&
diff -u expected current'
-echo >expected ' "tabs\t,\" (dq) and spaces"
- 1 files changed, 0 insertions(+), 0 deletions(-)'
+cat >expected <<\EOF
+ "tabs\t,\" (dq) and spaces"
+ 1 files changed, 0 insertions(+), 0 deletions(-)
+EOF
test_expect_success 'git-diff-tree rename with-funny applied' \
'git-diff-index -M -p $t0 |
git-apply --stat | sed -e "s/|.*//" -e "s/ *\$//" >current &&
diff -u expected current'
-echo >expected ' no-funny
+cat > expected <<\EOF
+ no-funny
"tabs\t,\" (dq) and spaces"
- 2 files changed, 3 insertions(+), 3 deletions(-)'
-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+EOF
test_expect_success 'git-diff-tree delete with-funny applied' \
'git-diff-index -p $t0 |
git-apply --stat | sed -e "s/|.*//" -e "s/ *\$//" >current &&
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <11486091783808-git-send-email-normalperson@yhbt.net>
None of the variables seem to conflict, so local was unnecessary.
Also replaced ${var:pos:len} with the sed equivalent.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t5500-fetch-pack.sh | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
62f64e95d24f90e61af0fa42d88300e41f60c277
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 92f12d9..f7625a6 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -12,11 +12,11 @@ # Test fetch-pack/upload-pack pair.
# Some convenience functions
-function add () {
- local name=$1
- local text="$@"
- local branch=${name:0:1}
- local parents=""
+add () {
+ name=$1
+ text="$@"
+ branch=`echo $name | sed -e 's/^\(.\).*$/\1/'`
+ parents=""
shift
while test $1; do
@@ -36,13 +36,13 @@ function add () {
eval ${branch}TIP=$commit
}
-function count_objects () {
+count_objects () {
ls .git/objects/??/* 2>>log2.txt | wc -l | tr -d " "
}
-function test_expect_object_count () {
- local message=$1
- local count=$2
+test_expect_object_count () {
+ message=$1
+ count=$2
output="$(count_objects)"
test_expect_success \
@@ -50,18 +50,18 @@ function test_expect_object_count () {
"test $count = $output"
}
-function pull_to_client () {
- local number=$1
- local heads=$2
- local count=$3
- local no_strict_count_check=$4
+pull_to_client () {
+ number=$1
+ heads=$2
+ count=$3
+ no_strict_count_check=$4
cd client
test_expect_success "$number pull" \
"git-fetch-pack -k -v .. $heads"
case "$heads" in *A*) echo $ATIP > .git/refs/heads/A;; esac
case "$heads" in *B*) echo $BTIP > .git/refs/heads/B;; esac
- git-symbolic-ref HEAD refs/heads/${heads:0:1}
+ git-symbolic-ref HEAD refs/heads/`echo $heads | sed -e 's/^\(.\).*$/\1/'`
test_expect_success "fsck" 'git-fsck-objects --full > fsck.txt 2>&1'
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 4/4] t6000lib: workaround a possible dash bug
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <11486091793385-git-send-email-normalperson@yhbt.net>
pdksh doesn't need this patch, of course bash works fine since
that what most users use.
Normally, 'var=val command' seems to work fine with dash, but
perhaps there's something weird going on with "$@". dash is
pretty widespread, so it'll be good to support this even though
it does seem like a bug in dash.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t6000lib.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
cba907ce0b1c0927fb15cbb5dd91a4129ff9a950
diff --git a/t/t6000lib.sh b/t/t6000lib.sh
index c6752af..d402621 100755
--- a/t/t6000lib.sh
+++ b/t/t6000lib.sh
@@ -69,7 +69,9 @@ on_committer_date()
{
_date=$1
shift 1
- GIT_COMMITTER_DATE=$_date "$@"
+ export GIT_COMMITTER_DATE="$_date"
+ "$@"
+ unset GIT_COMMITTER_DATE
}
# Execute a command and suppress any error output.
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 2/4] tests: Remove heredoc usage inside quotes
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <11486091783542-git-send-email-normalperson@yhbt.net>
The use of heredoc inside quoted strings doesn't seem to be
supported by dash. pdksh seems to handle it fine, however.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t2101-update-index-reupdate.sh | 48 ++++++++++++++++++++------------------
t/t4012-diff-binary.sh | 17 +++++--------
2 files changed, 31 insertions(+), 34 deletions(-)
250810154c837c6999a954fc6bc4318099b67c01
diff --git a/t/t2101-update-index-reupdate.sh b/t/t2101-update-index-reupdate.sh
index 77aed8d..a78ea7f 100755
--- a/t/t2101-update-index-reupdate.sh
+++ b/t/t2101-update-index-reupdate.sh
@@ -8,15 +8,16 @@ test_description='git-update-index --aga
. ./test-lib.sh
+cat > expected <<\EOF
+100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
+100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
+EOF
test_expect_success 'update-index --add' \
'echo hello world >file1 &&
echo goodbye people >file2 &&
git-update-index --add file1 file2 &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
-100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
-EOF'
+ cmp current expected'
test_expect_success 'update-index --again' \
'rm -f file1 &&
@@ -29,20 +30,22 @@ test_expect_success 'update-index --agai
echo happy - failed as expected
fi &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
-100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
-EOF'
+ cmp current expected'
+cat > expected <<\EOF
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index --remove --again' \
'git-update-index --remove --again &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
test_expect_success 'first commit' 'git-commit -m initial'
+cat > expected <<\EOF
+100644 53ab446c3f4e42ce9bb728a0ccb283a101be4979 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index again' \
'mkdir -p dir1 &&
echo hello world >dir1/file3 &&
@@ -52,11 +55,12 @@ test_expect_success 'update-index again'
echo happy >dir1/file3 &&
git-update-index --again &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 53ab446c3f4e42ce9bb728a0ccb283a101be4979 0 dir1/file3
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
+cat > expected <<\EOF
+100644 d7fb3f695f06c759dbf3ab00046e7cc2da22d10f 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index --update from subdir' \
'echo not so happy >file2 &&
cd dir1 &&
@@ -64,19 +68,17 @@ test_expect_success 'update-index --upda
git-update-index --again &&
cd .. &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 d7fb3f695f06c759dbf3ab00046e7cc2da22d10f 0 dir1/file3
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
+cat > expected <<\EOF
+100644 594fb5bb1759d90998e2bf2a38261ae8e243c760 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index --update with pathspec' \
'echo very happy >file2 &&
cat file2 >dir1/file3 &&
git-update-index --again dir1/ &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 594fb5bb1759d90998e2bf2a38261ae8e243c760 0 dir1/file3
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
test_done
diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh
index bdd95c0..323606c 100755
--- a/t/t4012-diff-binary.sh
+++ b/t/t4012-diff-binary.sh
@@ -16,25 +16,20 @@ test_expect_success 'prepare repository'
echo git >c &&
cat b b >d'
-test_expect_success 'diff without --binary' \
- 'git-diff | git-apply --stat --summary >current &&
- cmp current - <<\EOF
+cat > expected <<\EOF
a | 2 +-
b | Bin
c | 2 +-
d | Bin
4 files changed, 2 insertions(+), 2 deletions(-)
-EOF'
+EOF
+test_expect_success 'diff without --binary' \
+ 'git-diff | git-apply --stat --summary >current &&
+ cmp current expected'
test_expect_success 'diff with --binary' \
'git-diff --binary | git-apply --stat --summary >current &&
- cmp current - <<\EOF
- a | 2 +-
- b | Bin
- c | 2 +-
- d | Bin
- 4 files changed, 2 insertions(+), 2 deletions(-)
-EOF'
+ cmp current expected'
# apply needs to be able to skip the binary material correctly
# in order to report the line number of a corrupt patch.
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 0/4] fix tests so they run without needing bash
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu
I've tested these patches with bash, pdksh, and dash. dash seems
to be 7s faster than bash (28s vs 35s) when running `make test',
and just a hair faster than pdksh.
Herbert:
patches #2 and #4 are required for dash, but not for pdksh.
I'm not sure about #2, but I'm pretty certain the problem #4 works
around is a bug in dash.
[PATCH 1/4] t3300-funny-names: shell portability fixes
[PATCH 2/4] tests: Remove heredoc usage inside quotes
[PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
[PATCH 4/4] t6000lib: workaround a possible dash bug
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 0/4] fix tests so they run without needing bash
From: Junio C Hamano @ 2006-05-26 3:01 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1148609178788-git-send-email-normalperson@yhbt.net>
You are my hero.
I've really been wanting to get rid of bashism and trying to run
everything with dash was one of my goals. Although recent trend
seems to indicate people are more interested in getting rid of
shell scripts altogether, it is nice to see somebody actually
cares.
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Junio C Hamano @ 2006-05-26 3:02 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060526011153.GA27720@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I think we had hoped that one of the two tools would prove to be
> _the_ annotation/blame tool and would get used but thus far that
> hasn't happened.
I've been taking this as an indication that annotate/blame does
not actually matter in the real world.
Or git is not yet used in the real world. Or perhaps a bit of
both.
^ permalink raw reply
* Re: git-cvsserver wart?
From: Cameron McBride @ 2006-05-26 3:11 UTC (permalink / raw)
To: Martin Langhoff, git
In-Reply-To: <46a038f90605251419kd45fbj419565eabdd63182@mail.gmail.com>
On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> There's been some recent changes to cvsserver -- so version info is
> crucial. What git version are you using? Can you try with the lastest
> #master head from Junio? That's the latest and greatest...
sorry, my bad. This error was discovered using the git stable, v1.3.3.
Grabbing the latest at git://git.kernel.org/pub/scm/git/git.git
showed the same problem.
> If that doesn't fix it, can you post the logs? I think you have to
> declare CVS_LOG=/tmp/cvslog or somesuch.
I'm assuming you mean the log from git-cvsserver (set via git/config
with logfile=...)
Besides the log cutoff in the broken attempt, it appears the culprit
is a lack of arguments being passed down as that is the only
difference in the logs. Specifically, the working versions output
'Arguments : (something) ' which seemed to come from the
req_Argument()
subroutine around line 550 (in the case of newer CVS, the output is '--').
Anyhow, the error seems to be that $state->{args} is not getting
initialized. In the newer version, there seemed to be additional
uninitialized variables, e.g. $state->{prependdir}. These might be
signs of some larger problem (where the $state isn't getting set
properly).
To quiet it down and get it to run - a crude hack seemed to work
(included below). I didn't test any of this much, nor do I really
understand the whole of what's going on - my alterations just seemed
to allow 'cvs up' to complete without errors or warnings from both
clients. Not a very robust criteria, so please review.
Cameron
--
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 5ccca4f..a52e838 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1702,6 +1702,7 @@ sub argsfromdir
{
my $updater = shift;
+ $state->{args} = [] unless defined($state->{args});
$state->{args} = [] if ( scalar(@{$state->{args}}) == 1 and
$state->{args}[0] eq "." );
return if ( scalar ( @{$state->{args}} ) > 1 );
@@ -1729,7 +1730,11 @@ sub argsfromdir
foreach my $file ( @{$updater->gethead} )
{
next if ( $file->{filehash} eq "deleted" and not defined
( $state->{entries}{$file->{name}} ) );
- next unless ( $file->{name} =~ s/^$state->{prependdir}// );
+ if( defined($state->{prependdir} ) )
+ {
+ $file->{name} =~ s/^$state->{prependdir}//;
+ }
+ next unless ( $file->{name} );
push @{$state->{args}}, $file->{name};
}
}
@@ -1812,7 +1817,7 @@ sub filenamesplit
( $filepart, $dirpart ) = ( $2, $1 ) if ( $filename =~ /(.*)\/(.*)/ );
$dirpart .= "/";
- if ( $fixforlocaldir )
+ if ( $fixforlocaldir and defined($state->{prependdir}))
{
$dirpart =~ s/^$state->{prependdir}//;
}
@@ -1832,7 +1837,10 @@ sub filecleanup
}
$filename =~ s/^\.\///g;
- $filename = $state->{prependdir} . $filename;
+ if( defined($state->{prependdir}) )
+ {
+ $filename = $state->{prependdir} . $filename;
+ }
return $filename;
}
^ permalink raw reply related
* Re: t8001-annotate.sh fails on Mac OS X
From: Martin Langhoff @ 2006-05-26 3:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vpsi1qyi2.fsf@assigned-by-dhcp.cox.net>
On 5/26/06, Junio C Hamano <junkio@cox.net> wrote:
> Or git is not yet used in the real world.
Bah. Real world? Been there, not worth it...
m
^ permalink raw reply
* Re: git-cvsserver wart?
From: Martin Langhoff @ 2006-05-26 3:23 UTC (permalink / raw)
To: Cameron McBride; +Cc: git
In-Reply-To: <dcedf5e20605252011v6738dc9dg3d4801144d3e9898@mail.gmail.com>
On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> sorry, my bad. This error was discovered using the git stable, v1.3.3.
> Grabbing the latest at git://git.kernel.org/pub/scm/git/git.git
> showed the same problem.
Ok. You might want to retain that latest, it has some further fixes ;-)
> > If that doesn't fix it, can you post the logs? I think you have to
> > declare CVS_LOG=/tmp/cvslog or somesuch.
>
> I'm assuming you mean the log from git-cvsserver (set via git/config
> with logfile=...)
I was actually thinking of setting the environment at the client end:
CVS_CLIENT_LOG,
http://cvsbook.red-bean.com/cvsbook.html#$CVS_CLIENT_LOG but it looks
like you've got it mostly sorted.
> Besides the log cutoff in the broken attempt, it appears the culprit
> is a lack of arguments being passed down as that is the only
> difference in the logs.
Yes, I was guessing as much. I am still curious about what parameters
(and in what order) cvs 1.11.7 sends...
> To quiet it down and get it to run - a crude hack seemed to work
It looks reasonable as a means to shut it up, but perhaps if we can
figure out what the client is telling us... ;-)
martin
^ permalink raw reply
* Re: git-cvsserver wart?
From: Cameron McBride @ 2006-05-26 3:24 UTC (permalink / raw)
To: Martin Langhoff, git
In-Reply-To: <dcedf5e20605252011v6738dc9dg3d4801144d3e9898@mail.gmail.com>
Does cvs commit upstream work? In my testing, I can't get 'cvs ci' to
function on a git repo.
This seems to be broken with v1.3.3 and latest 1.3.3.ged90. The cvs
clients are the same as before 1.11.1p1 and 1.11.17
The cvs client exits with:
Index already exists in git repo
The log (for git version 1.3.3.ged90):
INFO - --------------- STARTING -----------------
DEBUG - Temporary directory is '/tmp/UvaWwud8fs'
DEBUG - req_Root : /export/home/cameron/ws/git_test/ntropy.git
DEBUG - req_Validresponses : ok error Valid-requests Checked-in
New-entry Checksum Copy-file Updated Created Update-existing Merged
Patched Rcs-diff Mode Mod-time Removed Remove-entry
Set-static-directory Clear-static-directory Set-sticky Clear-sticky
Template Set-checkin-prog Set-update-prog Notified Module-expansion
Wrapper-rcsOption M Mbinary E F MT DEBUG -
req_validrequests
DEBUG - SEND : Valid-requests remove add status Entry watchers ci tag
log co Modified Questionable admin Root history valid-requests
Global_option Argumentx annotate Valid-responses Unchanged Directory
rlog Argument expand-modules diff editors update
DEBUG - SEND : ok
DEBUG - Argument : -m
DEBUG - Argument : ncsa mod
DEBUG - req_Directory : localdir=.
repository=/export/home/cameron/ws/git_test/ntropy.git/master path=
directory= module=master
INFO - Received entry line '/README/1.7///' => 'README'
DEBUG - Argument : README
INFO - req_ci : [NULL]
WARN - file 'index' already exists in the git repository
Let me know if any additional information is useful, I didn't have
much time to dig into this.
Cameron
^ permalink raw reply
* Re: git-cvsserver wart?
From: Martin Langhoff @ 2006-05-26 3:28 UTC (permalink / raw)
To: Cameron McBride; +Cc: git
In-Reply-To: <dcedf5e20605252024q5bf51486o7cbf6cc396b18b5d@mail.gmail.com>
On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> WARN - file 'index' already exists in the git repository
This warning means that you are running git-cvsserver off a repo where
you also have a checkout. git-cvsserver really expects to be running
off a 'naked' or 'bare' repo. For read only ops I think it kind-of
works in a 'checkout' repo, but commits are a different story.
cheers,
m
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Stefan Pfetzing @ 2006-05-26 3:30 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <f3d7535d0605222020j2d581bd9j602752659a4b3ac2@mail.gmail.com>
Hi list,
2006/5/23, Stefan Pfetzing <stefan.pfetzing@gmail.com>:
> 2006/5/17, Jason Riedy <ejr@eecs.berkeley.edu>:
> > And pkgsrc itself works just fine without the silly g prefix,
> > or at least does for me as a mere user (and as well as it does
> > work). But if you intend on adding the package upstream, it'll
> > need something to cope with the g. And pkgsrc handles local
> > patches...
>
> Well I had some problems on NetBSD without the g prefix for the
> gnu coreutils - since then I always used that prefix.
...
Well finally - after some patching around access() and after figuring
out "merge" was broken in pkgsrc (and still is - I had to open a
problem report) - I got all tests to complete successfully.
bye
Stefan
P.S.: merge from devel/rcs uses /bin/diff3 on solaris which somehow
breaks merge.
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* Re: git-cvsserver wart?
From: Cameron McBride @ 2006-05-26 3:34 UTC (permalink / raw)
To: Martin Langhoff, git
In-Reply-To: <46a038f90605252028h556d0b2aob43f5c3dca8a5392@mail.gmail.com>
On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> > WARN - file 'index' already exists in the git repository
>
> This warning means that you are running git-cvsserver off a repo where
> you also have a checkout. git-cvsserver really expects to be running
> off a 'naked' or 'bare' repo. For read only ops I think it kind-of
> works in a 'checkout' repo, but commits are a different story.
hmmm, it is supposed to be a bare repo. perhaps I flubbed something
up. Can I safely delete this index file? It's in the repo.git
directory. Perhaps it got created on the initial import from CVS
(using cvsimport and cvsps)?
Cameron
^ permalink raw reply
* Re: git-cvsserver wart?
From: Cameron McBride @ 2006-05-26 3:57 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90605252023v5ff3fd65l9a991b3bbfa0a024@mail.gmail.com>
On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> Ok. You might want to retain that latest, it has some further fixes ;-)
sounds good.
> Yes, I was guessing as much. I am still curious about what parameters
> (and in what order) cvs 1.11.7 sends...
sure! now that I know CVS_CLIENT_LOG exists ... ;)
It points in basically the same direction, which is to say the newer
client passes an 'Argument -- ' which is what git-cvsserver seems to
be choking on.
The 'in' versions of the two
noup: cvs 1.11.1p1 that failed plane cvs update
work: cvs 1.11.17 that worked
--- cvs_noup.log.in 2006-05-25 23:44:21.000000000 -0400
+++ cvs_work.log.in 2006-05-25 23:48:38.000000000 -0400
@@ -1,6 +1,7 @@
Root /export/home/cameron/ws/git_test/ntropy.git
-Valid-responses ok error Valid-requests Checked-in New-entry Checksum
Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode
Mod-time Removed Remove-entry Set-static-directory
Clear-static-directory Set-sticky Clear-sticky Template
Set-checkin-prog Set-update-prog Notified Module-expansion
Wrapper-rcsOption M Mbinary E F MT
+Valid-responses ok error Valid-requests Checked-in New-entry Checksum
Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode
Mod-time Removed Remove-entry Set-static-directory
Clear-static-directory Set-sticky Clear-sticky Template Notified
Module-expansion Wrapper-rcsOption M Mbinary E F MT
valid-requests
+Argument --
Directory .
/export/home/cameron/ws/git_test/ntropy.git/master
Entry /.gitignore/1.1///
Thanks for your help!
Cameron
^ permalink raw reply
* Re: file name case-sensitivity issues
From: Christopher Faylor @ 2006-05-26 3:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vac96ufxv.fsf@assigned-by-dhcp.cox.net>
On Thu, May 25, 2006 at 11:17:48AM -0700, Junio C Hamano wrote:
>I have git installed on a Cygwin on NTFS at work...
Maybe this has been mentioned already but I wanted to point out that
Cygwin's mount has a "managed" option: "mount -o managed c:/foo /foo"
which causes cygwin to encode "problem" characters into the filename.
This means that there is a possibility that you'll run into the Windows
260 character max filename limit sooner so many people don't like to use
this option. However, since only uppercase characters and characters
like ">", ":", etc. are encoded, in practice you wouldn't see path
length problems *from this* very often. There is, of course, some
processing overhead involved in this, too, so using managed mode
will slow things down slightly.
We've been contemplating using Unicode functions in cygwin for a while
since those allow much longer path lengths but this is a massive change
and would potentially cause problems on Windows 9x. There has also been
some discussion of using native NT calls which, I believe, allow case
preservation like linux. However, those have a similar set of problems.
FYI,
cgf
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Fredrik Kuivinen @ 2006-05-26 4:32 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Stefan Pfetzing, Git Mailing List
In-Reply-To: <20060526011153.GA27720@spearce.org>
On Thu, May 25, 2006 at 09:11:53PM -0400, Shawn Pearce wrote:
> Stefan Pfetzing <stefan.pfetzing@gmail.com> wrote:
> > Hi,
> >
> > for some reason I could not yet figure out, t8001-annotate.sh fails at test
> > 18.
> >
> > --- snip ---
> > * ok 17: some edit
> > * expecting success: check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
> > Author A (expected 1, attributed 1) good
> > Author B1 (expected 1, attributed 1) good
> > Author D (expected 1, attributed 2) bad
> > Author A U Thor (expected 1, attributed 1) good
> > Author B2 (expected 1, attributed 1) good
> > Author B (expected 1, attributed 1) good
> > * FAIL 18: some edit
> > check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
> > * failed 1 among 18 test(s)
>
> I've been seeing the same failed test case for a long time now on
> my own Mac OS X system. I think it has to do with the "git blame"
> vs. "git annotate" war which never really happened.
>
> I think we had hoped that one of the two tools would prove to be
> _the_ annotation/blame tool and would get used but thus far that
> hasn't happened. Since they are two different implementations
> they also differ slightly over how they attribute a change across
> a merge, and in this case annotate is producing a different result
> from blame - but that different result isn't considered to be wrong
> so it hasn't been changed in annotate. Meanwhile the test has stayed
> broken as a reminder that these two generate different results.
>
I have planned to come up with a nice test suite for blame/annotate,
but I haven't got around to it yet.
I don't see this test failure on my Debian system. But it is true that
for some cases different blame/annotate outputs are equally correct,
however not in this case. Note that the incomplete line is attributed
to the commit with author D, but this commit did clearly not introduce
that line. The only correct answer, for that particular line, is the
commit with author C.
- Fredrik
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Linus Torvalds @ 2006-05-26 5:20 UTC (permalink / raw)
To: Martin Langhoff
Cc: Martin Langhoff, Git Mailing List, Junio C Hamano,
Johannes.Schindelin, spyderous, smurf
In-Reply-To: <46a038f90605251742p2435ae23k8bfbb98409a30c1c@mail.gmail.com>
On Fri, 26 May 2006, Martin Langhoff wrote:
>
> Call me slow, but I am still running and rerunning that gentoo import. ;-)
I'm doing it too, just for fun.
Of course, since I'm doing this on a machine that basically has a laptop
disk, the "just for fun" part is a bit sad. It's waiting for disk about
25% of the time ;/
And it's slow as hell. I really wish we could do better on the CVS import
front.
> The current import has reached ~200K commits, and .git is 450MB, while
> the checked out tree is 230MB (680MB with .git). At this stage, git
> repack -a -d is too memory hungry.
I've got 2GB in that puppy, and "repack -a -d" is fine for me. I'm not
quite up to 200k commits yet (I'm at 160k), but the repacking is certainly
faster than the rest of the import.. Gaah.
It's "git-rev-list --objects" that is the memory sucker for me, the
packing itself doesn't seem to be too bad.
The biggest cost seems to be git-write-tree, which is about 0.225 seconds
for me on that tree on that machine. Which _should_ mean that we could do
4 commits a second, but that sure as hell ain't how it works out. It seems
to do about 1.71 commits a second for me on that tree, which is pretty
damn pitiful. Some cvs overhead, and probably some other git overhead too.
(That's a 2GHz Merom, so the fact that you get ~6k commits per hour on
your 2GHz Opteron is about the same speed - I suspect you're also at least
partly limited by disk, our numbers seem to match pretty well).
200k commits at 6k commits per hour is about a day and a half (plus the
occasional packing load). Taking that long to import a CVS archive is
horrible. But I guess it _is_ several years of work, and I guess you
really have to do it only once, but still.
Linus
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Jakub Narebski @ 2006-05-26 5:29 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605252204590.5623@g5.osdl.org>
Linus Torvalds wrote:
> 200k commits at 6k commits per hour is about a day and a half (plus the
> occasional packing load). Taking that long to import a CVS archive is
> horrible. But I guess it _is_ several years of work, and I guess you
> really have to do it only once, but still.
And how parsecvs (which as far as I remember didn't have incremental mode)
compares wrt speed to git-cvsimport? It is supposed to be faster...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: Clean up sha1 file writing
From: Junio C Hamano @ 2006-05-26 5:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7virnv3qi6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> I think "kompare" (the KDE diff tool) is nicer.
>
> I'd love to give it a whirl, but aptitude says it will consume
> 73.5MB diskspace to install it, with download size 22.4MB, which
> makes me go ... hmmmm (my machines are currently KDE free so the
> above counts slurping in the kdelibs essentials).
It indeed is nicer ;-). I got a good laugh watching it smoothly
move the inserted hunk as I scrolled down.
^ 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