* [PATCH 5/8] t9402: Add missing &&; Code style
From: Torsten Bögershausen @ 2012-12-08 21:34 UTC (permalink / raw)
To: git; +Cc: tboegi, mmogilvi_git
Add missing && at 2 places
Re-formated the sub-shell parantheses (coding style)
Added missing ] in the test_expect_success header at 2 places
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t9402-git-cvsserver-refs.sh | 110 ++++++++++++++++++++----------------------
1 file changed, 52 insertions(+), 58 deletions(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index 2f63331..d525778 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -54,10 +54,12 @@ check_diff() {
vNew="$3"
rm -rf diffSandbox
git clone -q -n . diffSandbox &&
- ( cd diffSandbox &&
+ (
+ cd diffSandbox &&
git checkout "$vOld" &&
git apply -p0 --index <"../$diffFile" &&
- git diff --exit-code "$vNew" ) >check_diff_apply.out 2>&1
+ git diff --exit-code "$vNew"
+ ) >check_diff_apply.out 2>&1
}
#########
@@ -149,7 +151,8 @@ test_expect_success 'cvs co b1 [cvswork3]' '
'
test_expect_success 'edit cvswork3 and save diff' '
- ( cd cvswork3 &&
+ (
+ cd cvswork3 &&
sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
mv -f adir/afileNEW adir/afile &&
echo "afile5" >adir/afile5 &&
@@ -180,8 +183,7 @@ test_expect_success 'setup v1.2 on b1' '
'
test_expect_success 'cvs -f up (on b1 adir)' '
- ( cd cvswork/adir &&
- cvs -f up -d ) >cvs.log 2>&1 &&
+ ( cd cvswork/adir && cvs -f up -d ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1 &&
check_file cvswork t2 v1 &&
@@ -193,8 +195,7 @@ test_expect_success 'cvs -f up (on b1 adir)' '
'
test_expect_success 'cvs up (on b1 /)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1.2 &&
check_file cvswork t3 v1.2 &&
@@ -208,8 +209,7 @@ test_expect_success 'cvs up (on b1 /)' '
# Make sure "CVS/Tag" files didn't get messed up:
test_expect_success 'cvs up (on b1 /) (again; check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1.2 &&
check_file cvswork t3 v1.2 &&
@@ -223,8 +223,7 @@ test_expect_success 'cvs up (on b1 /) (again; check CVS/Tag files)' '
# update to another version:
test_expect_success 'cvs up -r v1' '
- ( cd cvswork &&
- cvs -f up -r v1 ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -r v1 ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1 &&
check_file cvswork t2 v1 &&
@@ -236,8 +235,7 @@ test_expect_success 'cvs up -r v1' '
'
test_expect_success 'cvs up' '
- ( cd cvswork &&
- cvs -f up ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1 &&
check_file cvswork t2 v1 &&
@@ -249,8 +247,7 @@ test_expect_success 'cvs up' '
'
test_expect_success 'cvs up (again; check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up -d ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1 &&
check_file cvswork t2 v1 &&
@@ -279,15 +276,16 @@ test_expect_success 'cvs co b2 [into cvswork2]' '
'
test_expect_success 'root dir edit [cvswork2]' '
- ( cd cvswork2 &&
- echo "Line 2" >>textfile.c &&
+ (
+ cd cvswork2 && echo "Line 2" >>textfile.c &&
! cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
cvs -f commit -m "edit textfile.c" textfile.c
) >cvsEdit1.log 2>&1
'
test_expect_success 'root dir rm file [cvswork2]' '
- ( cd cvswork2 &&
+ (
+ cd cvswork2 &&
cvs -f rm -f t2 &&
cvs -f diff -u >../cvsEdit2-empty.diff &&
! cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
@@ -295,8 +293,9 @@ test_expect_success 'root dir rm file [cvswork2]' '
) >cvsEdit2.log 2>&1
'
-test_expect_success 'subdir edit/add/rm files [cvswork2' '
- ( cd cvswork2 &&
+test_expect_success 'subdir edit/add/rm files [cvswork2]' '
+ (
+ cd cvswork2 &&
sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
rm adir/bdir/b2file &&
@@ -306,9 +305,10 @@ test_expect_success 'subdir edit/add/rm files [cvswork2' '
cvs -f add bdir/b4file &&
! cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
git fetch gitcvs.git b2:b2 &&
- ( cd .. &&
- ! cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
- ! cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
+ (
+ cd .. &&
+ ! cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
+ ! cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
) &&
cvs -f commit -m "various add/rm/edit"
) >cvs.log 2>&1
@@ -334,12 +334,14 @@ test_expect_success 'validate basic diffs saved during above cvswork2 edits' '
test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
rm -rf diffSandbox &&
git clone -q -n . diffSandbox &&
- ( cd diffSandbox &&
+ (
+ cd diffSandbox &&
git checkout v1 &&
git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
- git diff --exit-code v2 ) >"check_diff_apply.out" 2>&1
+ git diff --exit-code v2
+ ) >"check_diff_apply.out" 2>&1
'
test_expect_success 'validate v1.2 diff saved during last cvswork2 edit' '
@@ -353,8 +355,7 @@ test_expect_success 'validate v1.2 v1 diff saved during last cvswork2 edit' '
'
test_expect_success 'cvs up [cvswork2]' '
- ( cd cvswork2 &&
- cvs -f up ) >cvs.log 2>&1 &&
+ ( cd cvswork2 && cvs -f up ) >cvs.log 2>&1 &&
check_start_tree cvswork2 &&
check_file cvswork2 textfile.c v2 &&
check_file cvswork2 adir/afile v2 &&
@@ -365,8 +366,7 @@ test_expect_success 'cvs up [cvswork2]' '
'
test_expect_success 'cvs up -r b2 [back to cvswork]' '
- ( cd cvswork &&
- cvs -f up -r b2 ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -r b2 ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v2 &&
check_file cvswork adir/afile v2 &&
@@ -377,8 +377,7 @@ test_expect_success 'cvs up -r b2 [back to cvswork]' '
'
test_expect_success 'cvs up -r b1' '
- ( cd cvswork &&
- cvs -f up -r b1 ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -r b1 ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1.2 &&
check_file cvswork t3 v1.2 &&
@@ -391,8 +390,7 @@ test_expect_success 'cvs up -r b1' '
'
test_expect_success 'cvs up -A' '
- ( cd cvswork &&
- cvs -f up -A ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -A ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1 &&
check_file cvswork t2 v1 &&
@@ -404,8 +402,7 @@ test_expect_success 'cvs up -A' '
'
test_expect_success 'cvs up (check CVS/Tag files)' '
- ( cd cvswork &&
- cvs -f up ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1 &&
check_file cvswork t2 v1 &&
@@ -418,8 +415,7 @@ test_expect_success 'cvs up (check CVS/Tag files)' '
# This is not really legal CVS, but it seems to work anyway:
test_expect_success 'cvs up -r heads/b1' '
- ( cd cvswork &&
- cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1.2 &&
check_file cvswork t3 v1.2 &&
@@ -433,8 +429,7 @@ test_expect_success 'cvs up -r heads/b1' '
# But this should work even if CVS client checks -r more carefully:
test_expect_success 'cvs up -r heads_-s-b2 (cvsserver escape mechanism)' '
- ( cd cvswork &&
- cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v2 &&
check_file cvswork adir/afile v2 &&
@@ -447,8 +442,7 @@ test_expect_success 'cvs up -r heads_-s-b2 (cvsserver escape mechanism)' '
v1hash=$(git rev-parse v1)
test_expect_success 'cvs up -r $(git rev-parse v1)' '
test -n "$v1hash" &&
- ( cd cvswork &&
- cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
+ ( cd cvswork && cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
check_start_tree cvswork &&
check_file cvswork textfile.c v1 &&
check_file cvswork t2 v1 &&
@@ -460,23 +454,20 @@ test_expect_success 'cvs up -r $(git rev-parse v1)' '
'
test_expect_success 'cvs diff -r v1 -u' '
- ( cd cvswork &&
- cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
+ ( cd cvswork && cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
test ! -s cvsDiff.out &&
test ! -s cvs.log
'
test_expect_success 'cvs diff -N -r v2 -u' '
- ( cd cvswork &&
- ! cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
+ ( cd cvswork && ! cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
test ! -s cvs.log &&
test -s cvsDiff.out &&
check_diff cvsDiff.out v2 v1 >check_diff.out 2>&1
'
test_expect_success 'cvs diff -N -r v2 -r v1.2' '
- ( cd cvswork &&
- ! cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
+ ( cd cvswork && ! cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
test ! -s cvs.log &&
test -s cvsDiff.out &&
check_diff cvsDiff.out v2 v1.2 >check_diff.out 2>&1
@@ -484,17 +475,18 @@ test_expect_success 'cvs diff -N -r v2 -r v1.2' '
test_expect_success 'apply early [cvswork3] diff to b3' '
git clone -q . gitwork3 &&
- ( cd gitwork3 &&
+ (
+ cd gitwork3 &&
git checkout -b b3 v1 &&
git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
- git commit -m "cvswork3 edits applied" ) &&
+ git commit -m "cvswork3 edits applied"
+ ) &&
git fetch gitwork3 b3:b3 &&
git tag v3 b3
'
test_expect_success 'check [cvswork3] diff' '
- ( cd cvswork3 &&
- ! cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
+ ( cd cvswork3 && ! cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
test ! -s cvs.log &&
test -s cvsDiff.out &&
test $(grep Index: cvsDiff.out | wc -l) = 3 &&
@@ -503,8 +495,7 @@ test_expect_success 'check [cvswork3] diff' '
'
test_expect_success 'merge early [cvswork3] b3 with b1' '
- ( cd gitwork3 &&
- git merge "message" HEAD b1 )
+ ( cd gitwork3 && git merge "message" HEAD b1 ) &&
git fetch gitwork3 b3:b3 &&
git tag v3merged b3 &&
git push --tags gitcvs.git b3:b3
@@ -515,11 +506,13 @@ test_expect_success 'merge early [cvswork3] b3 with b1' '
# TODO: Validate that the .# file was saved properly, and then
# delete/ignore it when checking the tree.
test_expect_success 'cvs up dirty [cvswork3]' '
- ( cd cvswork3 &&
+ (
+ cd cvswork3 &&
cvs -f up &&
- ! cvs -f diff -N -u >"$WORKDIR/cvsDiff.out" ) >cvs.log 2>&1 &&
+ ! cvs -f diff -N -u >"$WORKDIR/cvsDiff.out"
+ ) >cvs.log 2>&1 &&
test -s cvsDiff.out &&
- test $(grep Index: cvsDiff.out | wc -l) = 2
+ test $(grep Index: cvsDiff.out | wc -l) = 2 &&
check_start_tree cvswork3 &&
check_file cvswork3 textfile.c v3merged &&
check_file cvswork3 t3 v3merged &&
@@ -534,8 +527,9 @@ test_expect_success 'cvs up dirty [cvswork3]' '
# TODO: test cvs status
-test_expect_success 'cvs commit [cvswork3' '
- ( cd cvswork3 &&
+test_expect_success 'cvs commit [cvswork3]' '
+ (
+ cd cvswork3 &&
cvs -f commit -m "dirty sandbox after auto-merge"
) >cvs.log 2>&1 &&
check_start_tree cvswork3 &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 6/8] t9402: Simplify git ls-tree
From: Torsten Bögershausen @ 2012-12-08 21:35 UTC (permalink / raw)
To: git; +Cc: tboegi, mmogilvi_git
Use "git ls-tree --name-only" which does not need a sed to filter out the sha
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t9402-git-cvsserver-refs.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index d525778..fadc80a 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -41,7 +41,7 @@ check_end_full_tree() {
sort <"$WORKDIR/check.list" >expected &&
find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
test_cmp expected act1 &&
- git ls-tree -r "$2" | sed -e "s/^.*blob [0-9a-fA-F]*[ ]*//" | sort >act2 &&
+ git ls-tree --name-only -r "$2" | sort >act2 &&
test_cmp expected act2 &&
rm expected act1 act2
}
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 6/8] t9402: Simplify git ls-tree
From: Torsten Bögershausen @ 2012-12-08 21:35 UTC (permalink / raw)
To: git; +Cc: tboegi, mmogilvi_git
Use "git ls-tree --name-only" which does not need a sed to filter out the sha
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t9402-git-cvsserver-refs.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index d525778..fadc80a 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -41,7 +41,7 @@ check_end_full_tree() {
sort <"$WORKDIR/check.list" >expected &&
find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
test_cmp expected act1 &&
- git ls-tree -r "$2" | sed -e "s/^.*blob [0-9a-fA-F]*[ ]*//" | sort >act2 &&
+ git ls-tree --name-only -r "$2" | sort >act2 &&
test_cmp expected act2 &&
rm expected act1 act2
}
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 7/8] t9402: Rename check.cvsCount and check.list
From: Torsten Bögershausen @ 2012-12-08 21:35 UTC (permalink / raw)
To: git; +Cc: tboegi, mmogilvi_git
Checking and comparing the number of line in check.list and check.cvsCount
had been replaced by comparing both files line by line.
Rename the filenames to make clear which is expected and which is actual:
check.list -> list.expected
check.cvsCount-> list.actual
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t9402-git-cvsserver-refs.sh | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index fadc80a..8dc4848 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -10,7 +10,7 @@ tags, branches and other git refspecs'
#########
check_start_tree() {
- rm -f "$WORKDIR/check.list"
+ rm -f "$WORKDIR/list.expected"
echo "start $1" >>"${WORKDIR}/check.log"
}
@@ -23,22 +23,22 @@ check_file() {
test_cmp "$WORKDIR/check.got" "$sandbox/$file"
stat=$?
echo "check_file $sandbox $file $ver : $stat" >>"$WORKDIR/check.log"
- echo "$file" >>"$WORKDIR/check.list"
+ echo "$file" >>"$WORKDIR/list.expected"
return $stat
}
check_end_tree() {
sandbox="$1" &&
- find "$sandbox" -name CVS -prune -o -type f -print >"$WORKDIR/check.cvsCount" &&
- sort <"$WORKDIR/check.list" >expected &&
- sort <"$WORKDIR/check.cvsCount" | sed -e "s%cvswork/%%" >actual &&
+ find "$sandbox" -name CVS -prune -o -type f -print >"$WORKDIR/list.actual" &&
+ sort <"$WORKDIR/list.expected" >expected &&
+ sort <"$WORKDIR/list.actual" | sed -e "s%cvswork/%%" >actual &&
test_cmp expected actual &&
rm expected actual
}
check_end_full_tree() {
sandbox="$1" &&
- sort <"$WORKDIR/check.list" >expected &&
+ sort <"$WORKDIR/list.expected" >expected &&
find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
test_cmp expected act1 &&
git ls-tree --name-only -r "$2" | sort >act2 &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 8/8] t9402: Use TABs for indentation
From: Torsten Bögershausen @ 2012-12-08 21:35 UTC (permalink / raw)
To: git; +Cc: tboegi, mmogilvi_git
Use TAB's for indentation
Put the closing ' at the begin of the line
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t9402-git-cvsserver-refs.sh | 746 +++++++++++++++++++++---------------------
1 file changed, 373 insertions(+), 373 deletions(-)
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index 8dc4848..8363dc0 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -10,56 +10,56 @@ tags, branches and other git refspecs'
#########
check_start_tree() {
- rm -f "$WORKDIR/list.expected"
- echo "start $1" >>"${WORKDIR}/check.log"
+ rm -f "$WORKDIR/list.expected"
+ echo "start $1" >>"${WORKDIR}/check.log"
}
check_file() {
- sandbox="$1"
- file="$2"
- ver="$3"
- GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
- >"$WORKDIR/check.got" 2>"$WORKDIR/check.stderr"
- test_cmp "$WORKDIR/check.got" "$sandbox/$file"
- stat=$?
- echo "check_file $sandbox $file $ver : $stat" >>"$WORKDIR/check.log"
- echo "$file" >>"$WORKDIR/list.expected"
- return $stat
+ sandbox="$1"
+ file="$2"
+ ver="$3"
+ GIT_DIR=$SERVERDIR git show "${ver}:${file}" \
+ >"$WORKDIR/check.got" 2>"$WORKDIR/check.stderr"
+ test_cmp "$WORKDIR/check.got" "$sandbox/$file"
+ stat=$?
+ echo "check_file $sandbox $file $ver : $stat" >>"$WORKDIR/check.log"
+ echo "$file" >>"$WORKDIR/list.expected"
+ return $stat
}
check_end_tree() {
- sandbox="$1" &&
- find "$sandbox" -name CVS -prune -o -type f -print >"$WORKDIR/list.actual" &&
- sort <"$WORKDIR/list.expected" >expected &&
- sort <"$WORKDIR/list.actual" | sed -e "s%cvswork/%%" >actual &&
- test_cmp expected actual &&
- rm expected actual
+ sandbox="$1" &&
+ find "$sandbox" -name CVS -prune -o -type f -print >"$WORKDIR/list.actual" &&
+ sort <"$WORKDIR/list.expected" >expected &&
+ sort <"$WORKDIR/list.actual" | sed -e "s%cvswork/%%" >actual &&
+ test_cmp expected actual &&
+ rm expected actual
}
check_end_full_tree() {
- sandbox="$1" &&
- sort <"$WORKDIR/list.expected" >expected &&
- find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
- test_cmp expected act1 &&
- git ls-tree --name-only -r "$2" | sort >act2 &&
- test_cmp expected act2 &&
- rm expected act1 act2
+ sandbox="$1" &&
+ sort <"$WORKDIR/list.expected" >expected &&
+ find "$sandbox" -name CVS -prune -o -type f -print | sed -e "s%$sandbox/%%" | sort >act1 &&
+ test_cmp expected act1 &&
+ git ls-tree --name-only -r "$2" | sort >act2 &&
+ test_cmp expected act2 &&
+ rm expected act1 act2
}
#########
check_diff() {
- diffFile="$1"
- vOld="$2"
- vNew="$3"
- rm -rf diffSandbox
- git clone -q -n . diffSandbox &&
- (
- cd diffSandbox &&
- git checkout "$vOld" &&
- git apply -p0 --index <"../$diffFile" &&
- git diff --exit-code "$vNew"
- ) >check_diff_apply.out 2>&1
+ diffFile="$1"
+ vOld="$2"
+ vNew="$3"
+ rm -rf diffSandbox
+ git clone -q -n . diffSandbox &&
+ (
+ cd diffSandbox &&
+ git checkout "$vOld" &&
+ git apply -p0 --index <"../$diffFile" &&
+ git diff --exit-code "$vNew"
+ ) >check_diff_apply.out 2>&1
}
#########
@@ -67,17 +67,17 @@ check_diff() {
cvs >/dev/null 2>&1
if test $? -ne 1
then
- skip_all='skipping git-cvsserver tests, cvs not found'
- test_done
+ skip_all='skipping git-cvsserver tests, cvs not found'
+ test_done
fi
if ! test_have_prereq PERL
then
- skip_all='skipping git-cvsserver tests, perl not available'
- test_done
+ skip_all='skipping git-cvsserver tests, perl not available'
+ test_done
fi
"$PERL_PATH" -e 'use DBI; use DBD::SQLite' >/dev/null 2>&1 || {
- skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
- test_done
+ skip_all='skipping git-cvsserver tests, Perl SQLite interface unavailable'
+ test_done
}
unset GIT_DIR GIT_CONFIG
@@ -91,414 +91,414 @@ export CVSROOT CVS_SERVER
rm -rf "$CVSWORK" "$SERVERDIR"
test_expect_success 'setup v1, b1' '
- echo "Simple text file" >textfile.c &&
- echo "t2" >t2 &&
- mkdir adir &&
- echo "adir/afile line1" >adir/afile &&
- echo "adir/afile line2" >>adir/afile &&
- echo "adir/afile line3" >>adir/afile &&
- echo "adir/afile line4" >>adir/afile &&
- echo "adir/a2file" >>adir/a2file &&
- mkdir adir/bdir &&
- echo "adir/bdir/bfile line 1" >adir/bdir/bfile &&
- echo "adir/bdir/bfile line 2" >>adir/bdir/bfile &&
- echo "adir/bdir/b2file" >adir/bdir/b2file &&
- git add textfile.c t2 adir &&
- git commit -q -m "First Commit (v1)" &&
- git tag v1 &&
- git branch b1 &&
- git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
- GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
- GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
+ echo "Simple text file" >textfile.c &&
+ echo "t2" >t2 &&
+ mkdir adir &&
+ echo "adir/afile line1" >adir/afile &&
+ echo "adir/afile line2" >>adir/afile &&
+ echo "adir/afile line3" >>adir/afile &&
+ echo "adir/afile line4" >>adir/afile &&
+ echo "adir/a2file" >>adir/a2file &&
+ mkdir adir/bdir &&
+ echo "adir/bdir/bfile line 1" >adir/bdir/bfile &&
+ echo "adir/bdir/bfile line 2" >>adir/bdir/bfile &&
+ echo "adir/bdir/b2file" >adir/bdir/b2file &&
+ git add textfile.c t2 adir &&
+ git commit -q -m "First Commit (v1)" &&
+ git tag v1 &&
+ git branch b1 &&
+ git clone -q --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.logfile "$SERVERDIR/gitcvs.log"
'
rm -rf cvswork
test_expect_success 'cvs co v1' '
- cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f -Q co -r v1 -d cvswork master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
rm -rf cvswork
test_expect_success 'cvs co b1' '
- cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f co -r b1 -d cvswork master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs co b1 [cvswork3]' '
- cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v1 &&
- check_file cvswork3 t2 v1 &&
- check_file cvswork3 adir/afile v1 &&
- check_file cvswork3 adir/a2file v1 &&
- check_file cvswork3 adir/bdir/bfile v1 &&
- check_file cvswork3 adir/bdir/b2file v1 &&
- check_end_full_tree cvswork3 v1
+ cvs -f co -r b1 -d cvswork3 master >cvs.log 2>&1 &&
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v1 &&
+ check_file cvswork3 t2 v1 &&
+ check_file cvswork3 adir/afile v1 &&
+ check_file cvswork3 adir/a2file v1 &&
+ check_file cvswork3 adir/bdir/bfile v1 &&
+ check_file cvswork3 adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork3 v1
'
test_expect_success 'edit cvswork3 and save diff' '
- (
- cd cvswork3 &&
- sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
+ (
+ cd cvswork3 &&
+ sed -e "s/line1/line1 - data/" adir/afile >adir/afileNEW &&
mv -f adir/afileNEW adir/afile &&
- echo "afile5" >adir/afile5 &&
- rm t2 &&
- cvs -f add adir/afile5 &&
- cvs -f rm t2 &&
- ! cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
- )
+ echo "afile5" >adir/afile5 &&
+ rm t2 &&
+ cvs -f add adir/afile5 &&
+ cvs -f rm t2 &&
+ ! cvs -f diff -N -u >"$WORKDIR/cvswork3edit.diff"
+ )
'
test_expect_success 'setup v1.2 on b1' '
- git checkout b1 &&
- echo "new v1.2" >t3 &&
- rm t2 &&
- sed -e "s/line3/line3 - more data/" adir/afile >adir/afileNEW &&
+ git checkout b1 &&
+ echo "new v1.2" >t3 &&
+ rm t2 &&
+ sed -e "s/line3/line3 - more data/" adir/afile >adir/afileNEW &&
mv -f adir/afileNEW adir/afile &&
- rm adir/a2file &&
- echo "a3file" >>adir/a3file &&
- echo "bfile line 3" >>adir/bdir/bfile &&
- rm adir/bdir/b2file &&
- echo "b3file" >adir/bdir/b3file &&
- mkdir cdir &&
- echo "cdir/cfile" >cdir/cfile &&
- git add -A cdir adir t3 t2 &&
- git commit -q -m 'v1.2' &&
- git tag v1.2 &&
- git push --tags gitcvs.git b1:b1
+ rm adir/a2file &&
+ echo "a3file" >>adir/a3file &&
+ echo "bfile line 3" >>adir/bdir/bfile &&
+ rm adir/bdir/b2file &&
+ echo "b3file" >adir/bdir/b3file &&
+ mkdir cdir &&
+ echo "cdir/cfile" >cdir/cfile &&
+ git add -A cdir adir t3 t2 &&
+ git commit -q -m 'v1.2' &&
+ git tag v1.2 &&
+ git push --tags gitcvs.git b1:b1
'
test_expect_success 'cvs -f up (on b1 adir)' '
- ( cd cvswork/adir && cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork/adir && cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up (on b1 /)' '
- ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_tree cvswork
'
# Make sure "CVS/Tag" files didn't get messed up:
test_expect_success 'cvs up (on b1 /) (again; check CVS/Tag files)' '
- ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_tree cvswork
+ ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_tree cvswork
'
# update to another version:
test_expect_success 'cvs up -r v1' '
- ( cd cvswork && cvs -f up -r v1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork && cvs -f up -r v1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up' '
- ( cd cvswork && cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork && cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'cvs up (again; check CVS/Tag files)' '
- ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ ( cd cvswork && cvs -f up -d ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'setup simple b2' '
- git branch b2 v1 &&
- git push --tags gitcvs.git b2:b2
+ git branch b2 v1 &&
+ git push --tags gitcvs.git b2:b2
'
test_expect_success 'cvs co b2 [into cvswork2]' '
- cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_tree cvswork
+ cvs -f co -r b2 -d cvswork2 master >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_tree cvswork
'
test_expect_success 'root dir edit [cvswork2]' '
- (
- cd cvswork2 && echo "Line 2" >>textfile.c &&
- ! cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
- cvs -f commit -m "edit textfile.c" textfile.c
- ) >cvsEdit1.log 2>&1
+ (
+ cd cvswork2 && echo "Line 2" >>textfile.c &&
+ ! cvs -f diff -u >"$WORKDIR/cvsEdit1.diff" &&
+ cvs -f commit -m "edit textfile.c" textfile.c
+ ) >cvsEdit1.log 2>&1
'
test_expect_success 'root dir rm file [cvswork2]' '
- (
- cd cvswork2 &&
- cvs -f rm -f t2 &&
- cvs -f diff -u >../cvsEdit2-empty.diff &&
- ! cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
- cvs -f commit -m "rm t2"
- ) >cvsEdit2.log 2>&1
+ (
+ cd cvswork2 &&
+ cvs -f rm -f t2 &&
+ cvs -f diff -u >../cvsEdit2-empty.diff &&
+ ! cvs -f diff -N -u >"$WORKDIR/cvsEdit2-N.diff" &&
+ cvs -f commit -m "rm t2"
+ ) >cvsEdit2.log 2>&1
'
test_expect_success 'subdir edit/add/rm files [cvswork2]' '
- (
- cd cvswork2 &&
- sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
- mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
- rm adir/bdir/b2file &&
- cd adir &&
- cvs -f rm bdir/b2file &&
- echo "4th file" >bdir/b4file &&
- cvs -f add bdir/b4file &&
- ! cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
- git fetch gitcvs.git b2:b2 &&
- (
- cd .. &&
- ! cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
- ! cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
- ) &&
- cvs -f commit -m "various add/rm/edit"
- ) >cvs.log 2>&1
+ (
+ cd cvswork2 &&
+ sed -e "s/line 1/line 1 (v2)/" adir/bdir/bfile >adir/bdir/bfileNEW &&
+ mv -f adir/bdir/bfileNEW adir/bdir/bfile &&
+ rm adir/bdir/b2file &&
+ cd adir &&
+ cvs -f rm bdir/b2file &&
+ echo "4th file" >bdir/b4file &&
+ cvs -f add bdir/b4file &&
+ ! cvs -f diff -N -u >"$WORKDIR/cvsEdit3.diff" &&
+ git fetch gitcvs.git b2:b2 &&
+ (
+ cd .. &&
+ ! cvs -f diff -u -N -r v1.2 >"$WORKDIR/cvsEdit3-v1.2.diff" &&
+ ! cvs -f diff -u -N -r v1.2 -r v1 >"$WORKDIR/cvsEdit3-v1.2-v1.diff"
+ ) &&
+ cvs -f commit -m "various add/rm/edit"
+ ) >cvs.log 2>&1
'
test_expect_success 'validate result of edits [cvswork2]' '
- git fetch gitcvs.git b2:b2 &&
- git tag v2 b2 &&
- git push --tags gitcvs.git b2:b2 &&
- check_start_tree cvswork2 &&
- check_file cvswork2 textfile.c v2 &&
- check_file cvswork2 adir/afile v2 &&
- check_file cvswork2 adir/a2file v2 &&
- check_file cvswork2 adir/bdir/bfile v2 &&
- check_file cvswork2 adir/bdir/b4file v2 &&
- check_end_full_tree cvswork2 v2
+ git fetch gitcvs.git b2:b2 &&
+ git tag v2 b2 &&
+ git push --tags gitcvs.git b2:b2 &&
+ check_start_tree cvswork2 &&
+ check_file cvswork2 textfile.c v2 &&
+ check_file cvswork2 adir/afile v2 &&
+ check_file cvswork2 adir/a2file v2 &&
+ check_file cvswork2 adir/bdir/bfile v2 &&
+ check_file cvswork2 adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork2 v2
'
test_expect_success 'validate basic diffs saved during above cvswork2 edits' '
- test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
- test ! -s cvsEdit2-empty.diff &&
- test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
- test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
- rm -rf diffSandbox &&
- git clone -q -n . diffSandbox &&
- (
- cd diffSandbox &&
- git checkout v1 &&
- git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
- git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
- git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
- git diff --exit-code v2
- ) >"check_diff_apply.out" 2>&1
+ test $(grep Index: cvsEdit1.diff | wc -l) = 1 &&
+ test ! -s cvsEdit2-empty.diff &&
+ test $(grep Index: cvsEdit2-N.diff | wc -l) = 1 &&
+ test $(grep Index: cvsEdit3.diff | wc -l) = 3 &&
+ rm -rf diffSandbox &&
+ git clone -q -n . diffSandbox &&
+ (
+ cd diffSandbox &&
+ git checkout v1 &&
+ git apply -p0 --index <"$WORKDIR/cvsEdit1.diff" &&
+ git apply -p0 --index <"$WORKDIR/cvsEdit2-N.diff" &&
+ git apply -p0 --directory=adir --index <"$WORKDIR/cvsEdit3.diff" &&
+ git diff --exit-code v2
+ ) >"check_diff_apply.out" 2>&1
'
test_expect_success 'validate v1.2 diff saved during last cvswork2 edit' '
- test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
- check_diff cvsEdit3-v1.2.diff v1.2 v2
+ test $(grep Index: cvsEdit3-v1.2.diff | wc -l) = 9 &&
+ check_diff cvsEdit3-v1.2.diff v1.2 v2
'
test_expect_success 'validate v1.2 v1 diff saved during last cvswork2 edit' '
- test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
- check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
+ test $(grep Index: cvsEdit3-v1.2-v1.diff | wc -l) = 9 &&
+ check_diff cvsEdit3-v1.2-v1.diff v1.2 v1
'
test_expect_success 'cvs up [cvswork2]' '
- ( cd cvswork2 && cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork2 &&
- check_file cvswork2 textfile.c v2 &&
- check_file cvswork2 adir/afile v2 &&
- check_file cvswork2 adir/a2file v2 &&
- check_file cvswork2 adir/bdir/bfile v2 &&
- check_file cvswork2 adir/bdir/b4file v2 &&
- check_end_full_tree cvswork2 v2
+ ( cd cvswork2 && cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork2 &&
+ check_file cvswork2 textfile.c v2 &&
+ check_file cvswork2 adir/afile v2 &&
+ check_file cvswork2 adir/a2file v2 &&
+ check_file cvswork2 adir/bdir/bfile v2 &&
+ check_file cvswork2 adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork2 v2
'
test_expect_success 'cvs up -r b2 [back to cvswork]' '
- ( cd cvswork && cvs -f up -r b2 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v2 &&
- check_file cvswork adir/afile v2 &&
- check_file cvswork adir/a2file v2 &&
- check_file cvswork adir/bdir/bfile v2 &&
- check_file cvswork adir/bdir/b4file v2 &&
- check_end_full_tree cvswork v2
+ ( cd cvswork && cvs -f up -r b2 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v2 &&
+ check_file cvswork adir/afile v2 &&
+ check_file cvswork adir/a2file v2 &&
+ check_file cvswork adir/bdir/bfile v2 &&
+ check_file cvswork adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork v2
'
test_expect_success 'cvs up -r b1' '
- ( cd cvswork && cvs -f up -r b1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_full_tree cvswork v1.2
+ ( cd cvswork && cvs -f up -r b1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_full_tree cvswork v1.2
'
test_expect_success 'cvs up -A' '
- ( cd cvswork && cvs -f up -A ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ ( cd cvswork && cvs -f up -A ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
test_expect_success 'cvs up (check CVS/Tag files)' '
- ( cd cvswork && cvs -f up ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ ( cd cvswork && cvs -f up ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
# This is not really legal CVS, but it seems to work anyway:
test_expect_success 'cvs up -r heads/b1' '
- ( cd cvswork && cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1.2 &&
- check_file cvswork t3 v1.2 &&
- check_file cvswork adir/afile v1.2 &&
- check_file cvswork adir/a3file v1.2 &&
- check_file cvswork adir/bdir/bfile v1.2 &&
- check_file cvswork adir/bdir/b3file v1.2 &&
- check_file cvswork cdir/cfile v1.2 &&
- check_end_full_tree cvswork v1.2
+ ( cd cvswork && cvs -f up -r heads/b1 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1.2 &&
+ check_file cvswork t3 v1.2 &&
+ check_file cvswork adir/afile v1.2 &&
+ check_file cvswork adir/a3file v1.2 &&
+ check_file cvswork adir/bdir/bfile v1.2 &&
+ check_file cvswork adir/bdir/b3file v1.2 &&
+ check_file cvswork cdir/cfile v1.2 &&
+ check_end_full_tree cvswork v1.2
'
# But this should work even if CVS client checks -r more carefully:
test_expect_success 'cvs up -r heads_-s-b2 (cvsserver escape mechanism)' '
- ( cd cvswork && cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v2 &&
- check_file cvswork adir/afile v2 &&
- check_file cvswork adir/a2file v2 &&
- check_file cvswork adir/bdir/bfile v2 &&
- check_file cvswork adir/bdir/b4file v2 &&
- check_end_full_tree cvswork v2
+ ( cd cvswork && cvs -f up -r heads_-s-b2 ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v2 &&
+ check_file cvswork adir/afile v2 &&
+ check_file cvswork adir/a2file v2 &&
+ check_file cvswork adir/bdir/bfile v2 &&
+ check_file cvswork adir/bdir/b4file v2 &&
+ check_end_full_tree cvswork v2
'
v1hash=$(git rev-parse v1)
test_expect_success 'cvs up -r $(git rev-parse v1)' '
- test -n "$v1hash" &&
- ( cd cvswork && cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
- check_start_tree cvswork &&
- check_file cvswork textfile.c v1 &&
- check_file cvswork t2 v1 &&
- check_file cvswork adir/afile v1 &&
- check_file cvswork adir/a2file v1 &&
- check_file cvswork adir/bdir/bfile v1 &&
- check_file cvswork adir/bdir/b2file v1 &&
- check_end_full_tree cvswork v1
+ test -n "$v1hash" &&
+ ( cd cvswork && cvs -f up -r "$v1hash" ) >cvs.log 2>&1 &&
+ check_start_tree cvswork &&
+ check_file cvswork textfile.c v1 &&
+ check_file cvswork t2 v1 &&
+ check_file cvswork adir/afile v1 &&
+ check_file cvswork adir/a2file v1 &&
+ check_file cvswork adir/bdir/bfile v1 &&
+ check_file cvswork adir/bdir/b2file v1 &&
+ check_end_full_tree cvswork v1
'
test_expect_success 'cvs diff -r v1 -u' '
- ( cd cvswork && cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvsDiff.out &&
- test ! -s cvs.log
+ ( cd cvswork && cvs -f diff -r v1 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvsDiff.out &&
+ test ! -s cvs.log
'
test_expect_success 'cvs diff -N -r v2 -u' '
- ( cd cvswork && ! cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- check_diff cvsDiff.out v2 v1 >check_diff.out 2>&1
+ ( cd cvswork && ! cvs -f diff -N -r v2 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ check_diff cvsDiff.out v2 v1 >check_diff.out 2>&1
'
test_expect_success 'cvs diff -N -r v2 -r v1.2' '
- ( cd cvswork && ! cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- check_diff cvsDiff.out v2 v1.2 >check_diff.out 2>&1
+ ( cd cvswork && ! cvs -f diff -N -r v2 -r v1.2 -u ) >cvsDiff.out 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ check_diff cvsDiff.out v2 v1.2 >check_diff.out 2>&1
'
test_expect_success 'apply early [cvswork3] diff to b3' '
- git clone -q . gitwork3 &&
- (
- cd gitwork3 &&
- git checkout -b b3 v1 &&
- git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
- git commit -m "cvswork3 edits applied"
- ) &&
- git fetch gitwork3 b3:b3 &&
- git tag v3 b3
+ git clone -q . gitwork3 &&
+ (
+ cd gitwork3 &&
+ git checkout -b b3 v1 &&
+ git apply -p0 --index <"$WORKDIR/cvswork3edit.diff" &&
+ git commit -m "cvswork3 edits applied"
+ ) &&
+ git fetch gitwork3 b3:b3 &&
+ git tag v3 b3
'
test_expect_success 'check [cvswork3] diff' '
- ( cd cvswork3 && ! cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
- test ! -s cvs.log &&
- test -s cvsDiff.out &&
- test $(grep Index: cvsDiff.out | wc -l) = 3 &&
- test_cmp cvsDiff.out cvswork3edit.diff &&
- check_diff cvsDiff.out v1 v3 >check_diff.out 2>&1
+ ( cd cvswork3 && ! cvs -f diff -N -u ) >"$WORKDIR/cvsDiff.out" 2>cvs.log &&
+ test ! -s cvs.log &&
+ test -s cvsDiff.out &&
+ test $(grep Index: cvsDiff.out | wc -l) = 3 &&
+ test_cmp cvsDiff.out cvswork3edit.diff &&
+ check_diff cvsDiff.out v1 v3 >check_diff.out 2>&1
'
test_expect_success 'merge early [cvswork3] b3 with b1' '
- ( cd gitwork3 && git merge "message" HEAD b1 ) &&
- git fetch gitwork3 b3:b3 &&
- git tag v3merged b3 &&
- git push --tags gitcvs.git b3:b3
+ ( cd gitwork3 && git merge "message" HEAD b1 ) &&
+ git fetch gitwork3 b3:b3 &&
+ git tag v3merged b3 &&
+ git push --tags gitcvs.git b3:b3
'
# This test would fail if cvsserver properly created a ".#afile"* file
@@ -506,45 +506,45 @@ test_expect_success 'merge early [cvswork3] b3 with b1' '
# TODO: Validate that the .# file was saved properly, and then
# delete/ignore it when checking the tree.
test_expect_success 'cvs up dirty [cvswork3]' '
- (
- cd cvswork3 &&
- cvs -f up &&
- ! cvs -f diff -N -u >"$WORKDIR/cvsDiff.out"
- ) >cvs.log 2>&1 &&
- test -s cvsDiff.out &&
- test $(grep Index: cvsDiff.out | wc -l) = 2 &&
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v3merged &&
- check_file cvswork3 t3 v3merged &&
- check_file cvswork3 adir/afile v3merged &&
- check_file cvswork3 adir/a3file v3merged &&
- check_file cvswork3 adir/afile5 v3merged &&
- check_file cvswork3 adir/bdir/bfile v3merged &&
- check_file cvswork3 adir/bdir/b3file v3merged &&
- check_file cvswork3 cdir/cfile v3merged &&
- check_end_full_tree cvswork3 v3merged
+ (
+ cd cvswork3 &&
+ cvs -f up &&
+ ! cvs -f diff -N -u >"$WORKDIR/cvsDiff.out"
+ ) >cvs.log 2>&1 &&
+ test -s cvsDiff.out &&
+ test $(grep Index: cvsDiff.out | wc -l) = 2 &&
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v3merged &&
+ check_file cvswork3 t3 v3merged &&
+ check_file cvswork3 adir/afile v3merged &&
+ check_file cvswork3 adir/a3file v3merged &&
+ check_file cvswork3 adir/afile5 v3merged &&
+ check_file cvswork3 adir/bdir/bfile v3merged &&
+ check_file cvswork3 adir/bdir/b3file v3merged &&
+ check_file cvswork3 cdir/cfile v3merged &&
+ check_end_full_tree cvswork3 v3merged
'
# TODO: test cvs status
test_expect_success 'cvs commit [cvswork3]' '
- (
- cd cvswork3 &&
- cvs -f commit -m "dirty sandbox after auto-merge"
- ) >cvs.log 2>&1 &&
- check_start_tree cvswork3 &&
- check_file cvswork3 textfile.c v3merged &&
- check_file cvswork3 t3 v3merged &&
- check_file cvswork3 adir/afile v3merged &&
- check_file cvswork3 adir/a3file v3merged &&
- check_file cvswork3 adir/afile5 v3merged &&
- check_file cvswork3 adir/bdir/bfile v3merged &&
- check_file cvswork3 adir/bdir/b3file v3merged &&
- check_file cvswork3 cdir/cfile v3merged &&
- check_end_full_tree cvswork3 v3merged &&
- git fetch gitcvs.git b3:b4 &&
- git tag v4.1 b4 &&
- git diff --exit-code v4.1 v3merged >check_diff_apply.out 2>&1
+ (
+ cd cvswork3 &&
+ cvs -f commit -m "dirty sandbox after auto-merge"
+ ) >cvs.log 2>&1 &&
+ check_start_tree cvswork3 &&
+ check_file cvswork3 textfile.c v3merged &&
+ check_file cvswork3 t3 v3merged &&
+ check_file cvswork3 adir/afile v3merged &&
+ check_file cvswork3 adir/a3file v3merged &&
+ check_file cvswork3 adir/afile5 v3merged &&
+ check_file cvswork3 adir/bdir/bfile v3merged &&
+ check_file cvswork3 adir/bdir/b3file v3merged &&
+ check_file cvswork3 cdir/cfile v3merged &&
+ check_end_full_tree cvswork3 v3merged &&
+ git fetch gitcvs.git b3:b4 &&
+ git tag v4.1 b4 &&
+ git diff --exit-code v4.1 v3merged >check_diff_apply.out 2>&1
'
test_done
--
1.8.0.197.g5a90748
^ permalink raw reply related
* Re: Feature Request - Hide ignored files before checkout
From: Chris Rorvick @ 2012-12-09 5:54 UTC (permalink / raw)
To: Matthew Ciancio; +Cc: git
In-Reply-To: <000001cdd5a0$fd23adf0$f76b09d0$@gmail.com>
On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio
<matthew.ciancio16@gmail.com> wrote:
> Hi Chris,
>
> Yes, I don't think I have explained myself well enough.
>
> When I say "disappear" I do not mean "get deleted", I mean: go out of view
> just like foo.txt does, as it is committed to branchB and not merged into
> branchA.
>
> So I am saying that I think .gitignored files should behave partly like
> committed and un-merged files, in the sense that they disappear when
> checking out to a different branch.
> I don't want to commit these files (which would give me the behaviour I
> want), because they are binary/OS specific and really do not belong in the
> repository, BUT I need them to run/build certain committed files.
>
> To be concrete: I want ignore.txt to be ignored in branchB and hence
> disappear (in the same way that foo.txt will), when checking out to branchA.
> When I checkout back to branchB I want ignore.txt to reappear (in the same
> way that foo.txt will).
>
> I understand why this behaviour is not happening (because my .gitignore
> files are different between the branches), but I am saying that I would like
> to have the option to keep my .gitignore'd files local to the branch they
> are in.
>
> E.g. I currently have a branch with all these binary files that are required
> to run an application on my OS, but when I checkout to another branch I do
> not need or want those binary files anymore (at least not until I checkout
> back into the branch I just came from).
>
> Please tell me if that still doesn't make sense.
Hi Matthew,
Cc'ing the list to benefit from the review of others.
Not wanting the files in the repository seems to be in conflict with
the desire to have them under its control (i.e., disappear/reappear
behavior.) I understand not wanting to commit dependencies, but why
do you need them to disappear? Why not just put them somewhere where
they can be used when needed and left alone when not?
If you do want this behavior, it seems like you should just commit the
files on the respective branch. Maybe someone else will have a better
idea, though.
Chris
^ permalink raw reply
* RE: Feature Request - Hide ignored files before checkout
From: Matthew Ciancio @ 2012-12-09 8:10 UTC (permalink / raw)
To: 'Chris Rorvick'; +Cc: git
In-Reply-To: <CAEUsAPaqSQVSNaiJUO3Sfms3Rt2vzsciczXK0impHnXQ52u7mA@mail.gmail.com>
I'm glad we are on the same page now and thanks for bringing in others.
" Not wanting the files in the repository seems to be in conflict with the
desire to have them under its control (i.e., disappear/reappear behavior.) "
Sorry, when I said I didn't want them in the repository, I meant I wanted
them there (in the repository folder), but not within Git commit logs and
not being tracked, etc.
Committing binary/OS specific files just doesn't sit right with me and I am
sure many others.
"... but why do you need them to disappear? Why not just put them somewhere
where they can be used when needed and left alone when not?"
I could do that (keep them in a folder that will be left alone), but in my
specific case it would mean the executable files (ignored files placed in
this new folder) will not execute because of the change in location and
hence would require a lot of code change to suit.
>From my perspective I don't see the harm in having this as a new feature
(via flags in the .gitignore file, if you don't want to make it default
behaviour). Is there some reason I don't know about, maybe to do with the
Git source code?
-----Original Message-----
From: chris.rorvick@gmail.com [mailto:chris.rorvick@gmail.com] On Behalf Of
Chris Rorvick
Sent: Sunday, 9 December 2012 4:54 PM
To: Matthew Ciancio
Cc: git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout
On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio
<matthew.ciancio16@gmail.com> wrote:
> Hi Chris,
>
> Yes, I don't think I have explained myself well enough.
>
> When I say "disappear" I do not mean "get deleted", I mean: go out of
> view just like foo.txt does, as it is committed to branchB and not
> merged into branchA.
>
> So I am saying that I think .gitignored files should behave partly
> like committed and un-merged files, in the sense that they disappear
> when checking out to a different branch.
> I don't want to commit these files (which would give me the behaviour
> I want), because they are binary/OS specific and really do not belong
> in the repository, BUT I need them to run/build certain committed files.
>
> To be concrete: I want ignore.txt to be ignored in branchB and hence
> disappear (in the same way that foo.txt will), when checking out to
branchA.
> When I checkout back to branchB I want ignore.txt to reappear (in the
> same way that foo.txt will).
>
> I understand why this behaviour is not happening (because my
> .gitignore files are different between the branches), but I am saying
> that I would like to have the option to keep my .gitignore'd files
> local to the branch they are in.
>
> E.g. I currently have a branch with all these binary files that are
> required to run an application on my OS, but when I checkout to
> another branch I do not need or want those binary files anymore (at
> least not until I checkout back into the branch I just came from).
>
> Please tell me if that still doesn't make sense.
Hi Matthew,
Cc'ing the list to benefit from the review of others.
Not wanting the files in the repository seems to be in conflict with the
desire to have them under its control (i.e., disappear/reappear
behavior.) I understand not wanting to commit dependencies, but why do you
need them to disappear? Why not just put them somewhere where they can be
used when needed and left alone when not?
If you do want this behavior, it seems like you should just commit the files
on the respective branch. Maybe someone else will have a better idea,
though.
Chris
^ permalink raw reply
* Re: Feature Request - Hide ignored files before checkout
From: Junio C Hamano @ 2012-12-09 9:04 UTC (permalink / raw)
To: Chris Rorvick; +Cc: Matthew Ciancio, git
In-Reply-To: <CAEUsAPaHJ+N0EnxGuVkRqcmY0fUy+4myMiWtd1_vu1vRL763JQ@mail.gmail.com>
Chris Rorvick <chris@rorvick.com> writes:
> It's not in branchA, it's just no longer ignored because your changes
> to .gitignore were effectively reverted by jumping back to the commit
> that branchA points to.
> ...
> "hide/reappear" is the equivalent to saying "deleted/created" in the
> case of a tracked file in your working tree. But how would Git cause
> an untracked file to reappear? By definition, it doesn't know
> anything about the file.
Nicely explained. To make something simply disappear, you could
remove it, but that is obviously not enough to make it reappear. It
has to be stashed away somewhere before it gets removed, and in the
context of (any) SCM, that is done by committing.
You may have Mac and Windows branches, each of which needs to link
with vendor supplied object file blackbox.o with the rest of the
source. It is understandable if a project does not want to mix such
platform specific black box binaries in the history of the source.
But that does not necessarily mean the project can totally ignore
what specific black box binary was meant to be used with the rest of
the source.
After you released the v1.0 of your product for both Macintosh and
Windows, the vendor may supply updated versions of the blackbox.o
binary for these platforms, and you would start working toward v1.1
of your product using these updated copies of objects. Then you
find problems in the released v1.0 software. Without keeping track
of which version of the object was used to build the released v1.0,
you cannot diagnose, build and test a maintenance update v1.0.1.
The project may add new Macintosh (or Windows) developers. You can
tell new Macintosh developers to clone and checkout mac branch, and
in the same e-mail, give them the untracked blackbox.o file for that
platform, but you have to rely on human not making mistakes (you may
mistakenly send Windows version of blackbox.o to him, you may send
stale Macintosh version, the developer may misplace the new one and
keep using the stale one, etc. etc.).
Some people commit blackbox.o on each platform-specific branch, or
all branches share blackbox-win.o and blackbox-mac.o, only one of
which is used at any given branch, for this exact reason.
The project, for licensing reasons, may not have rights to
distribute such a blackbox object file along with its sources, but
the vendor of the blackbox object may allow individual developer to
download and link it from vendor's site. In such a case, the
project would not want to (and is not allowed to) commit such object
file. One approach I have seen used in such a case is to arrange
the build procedure so that these individual developers can drop
such an external object next to the project directory, and refer to
it as ../blackbox.o when linking.
So "these files are moved away from the working tree upon checking
another branch out, and moved back into the working tree upon
checking out this branch" is pretty much outside the scope of any
SCM. It is not very interesting, as it is not necessary to solve
any real world problem.
Of course, the users can do whatever moving/copying/renaming of
untracked files in their post-checkout hook to be run when a new
branch is checked out.
^ permalink raw reply
* Re: [PATCH] gitk: read and write a repository specific configuration file
From: Junio C Hamano @ 2012-12-09 9:18 UTC (permalink / raw)
To: Łukasz Stelmach; +Cc: git, mbranchaud, paulus
In-Reply-To: <1354966067-2865-1-git-send-email-stlman@poczta.fm>
Łukasz Stelmach <stlman@poczta.fm> writes:
> Enable gitk read and write repository specific configuration
> file: ".git/k" if the file exists. To make gitk use the local
> file simply create one, e.g. with the touch(1) command.
>
> This is very useful if one uses different views for different
> repositories. Now there is no need to store all of them in
> ~/.gitk and make the views list needlessly long.
I do not use gitk heavily myself, but I have a mixed feeling about
this patch.
Forking the configuration from the one true ~/.gitk is easy; it is
just the matter of copying it to repository specific location. Once
forked, however, it is very hard to merge these configuration files
sprinkled across repositories back, or more importantly, change the
settings globally. Imagine you just got a new monitor that is a lot
finer grained than the one you have been usingq, and your choice of
font size has been specified in terms of pixels; you would want to
show all gitk windows in larger font now, regardless of the
repository, but you now have to go to 47 different configuration
files and update them.
So I suspect that this may introduce more trouble than it is worth
for users and should not be sold with a "This is very useful" label.
At best, it is "This may be useful"; otherwise the feature may end
up harming our users. I'd phrase it without judging if it is good
or bad for the users, perhaps like this:
This allows one to specify different views for different
repositories.
In any case, the filename .git/k may be _cute_, but I do not think
we would want to see:
$ ls .git
branches config HEAD index k objects
COMMIT_EDITMSG description hooks info logs refs
It is too cryptic, unless the user _knows_ 'k' is for gitk. I'd
call it $GIT_DIR/gitkconfig or something, if I were supportive for
this feature (which I am not enthusiastic, yet).
Thanks.
^ permalink raw reply
* Re: [PATCH] shortlog: Fix wrapping lines of wraplen
From: Junio C Hamano @ 2012-12-09 9:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Jan H. Schoenherr
In-Reply-To: <1354993767-7455-1-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> A recent commit [1] fixed a off-by-one wrapping error. As
> a side-effect, add_wrapped_shortlog_msg() needs to be changed to always
> append a newline.
Could you clarify "As a side effect" a bit more? Do you mean
something like this?
Earlier strbuf_add_wrapped_text() ended its output with a
newline only when the end of the text exactly fitted in wrap
length, due to the off-by-one error fixed with 14e1a4e (utf8:
fix off-by-one wrapping of text, 2012-10-18). There was a hack
in add_wrapped_shortlog_msg() function to compensate for this
bug.
With the bug fixed, the function never ends its output with a
newline, and the caller needs to unconditionally add one.
>
> [1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one
> wrapping of text
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
> builtin/shortlog.c | 3 +--
> t/t4201-shortlog.sh | 24 ++++++++++++++++++++++++
> 2 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/shortlog.c b/builtin/shortlog.c
> index b316cf3..db5b57d 100644
> --- a/builtin/shortlog.c
> +++ b/builtin/shortlog.c
> @@ -307,8 +307,7 @@ static void add_wrapped_shortlog_msg(struct strbuf *sb, const char *s,
> const struct shortlog *log)
> {
> int col = strbuf_add_wrapped_text(sb, s, log->in1, log->in2, log->wrap);
> - if (col != log->wrap)
> - strbuf_addch(sb, '\n');
> + strbuf_addch(sb, '\n');
> }
>
> void shortlog_output(struct shortlog *log)
> diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
> index 6872ba1..02ac978 100755
> --- a/t/t4201-shortlog.sh
> +++ b/t/t4201-shortlog.sh
> @@ -120,6 +120,30 @@ test_expect_success 'shortlog from non-git directory' '
> test_cmp expect out
> '
>
> +test_expect_success 'shortlog should add newline when input line matches wraplen' '
> + cat >expect <<\EOF &&
> +A U Thor (2):
> + bbbbbbbbbbbbbbbbbb: bbbbbbbb bbb bbbb bbbbbbb bb bbbb bbb bbbbb bbbbbb
> + aaaaaaaaaaaaaaaaaaaaaa: aaaaaa aaaaaaaaaa aaaa aaaaaaaa aa aaaa aa aaa
> +
> +EOF
> + git shortlog -w >out <<\EOF &&
> +commit 0000000000000000000000000000000000000001
> +Author: A U Thor <author@example.com>
> +Date: Thu Apr 7 15:14:13 2005 -0700
> +
> + aaaaaaaaaaaaaaaaaaaaaa: aaaaaa aaaaaaaaaa aaaa aaaaaaaa aa aaaa aa aaa
> +
> +commit 0000000000000000000000000000000000000002
> +Author: A U Thor <author@example.com>
> +Date: Thu Apr 7 15:14:13 2005 -0700
> +
> + bbbbbbbbbbbbbbbbbb: bbbbbbbb bbb bbbb bbbbbbb bb bbbb bbb bbbbb bbbbbb
> +
> +EOF
> + test_cmp expect out
> +'
> +
> iconvfromutf8toiso88591() {
> printf "%s" "$*" | iconv -f UTF-8 -t ISO8859-1
> }
^ permalink raw reply
* Re: [PATCH 8/8] t9402: Use TABs for indentation
From: Junio C Hamano @ 2012-12-09 9:43 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, mmogilvi_git
In-Reply-To: <201212082235.54386.tboegi@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> Use TAB's for indentation
> Put the closing ' at the begin of the line
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
The entire series looked cleanly done. I've tweaked the last patch
a bit to wrap overlong lines, though.
Thanks.
^ permalink raw reply
* Re: [PATCH 8/8] t9402: Use TABs for indentation
From: Torsten Bögershausen @ 2012-12-09 10:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, mmogilvi_git
In-Reply-To: <7v4njvef20.fsf@alter.siamese.dyndns.org>
On 09.12.12 10:43, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
>> Use TAB's for indentation
>> Put the closing ' at the begin of the line
>>
>> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
>> ---
> The entire series looked cleanly done. I've tweaked the last patch
> a bit to wrap overlong lines, though.
>
> Thanks.
Thanks Junio,
PS: for some reason I don't get any mails to my
(google) account any more, which I use to read the list.
Am I the only one having this problem?
^ permalink raw reply
* [PATCH] Makefile: whitespace style fixes in macro definitions
From: Stefano Lattarini @ 2012-12-09 10:36 UTC (permalink / raw)
To: git; +Cc: gitster
Consistently use a single space before and after the "=" (or ":=", "+=",
etc.) in assignments to make macros. Granted, this was not a big deal,
but I did find the needless inconsistency quite distracting.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
---
Makefile | 56 ++++++++++++++++++++++++++++----------------------------
config.mak.in | 2 +-
t/Makefile | 2 +-
3 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/Makefile b/Makefile
index 4ad6fbd..736ecd4 100644
--- a/Makefile
+++ b/Makefile
@@ -374,7 +374,7 @@ htmldir = share/doc/git-doc
ETC_GITCONFIG = $(sysconfdir)/gitconfig
ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
lib = lib
-# DESTDIR=
+# DESTDIR =
pathsep = :
export prefix bindir sharedir sysconfdir gitwebdir localedir
@@ -575,9 +575,9 @@ endif
export PERL_PATH
export PYTHON_PATH
-LIB_FILE=libgit.a
-XDIFF_LIB=xdiff/lib.a
-VCSSVN_LIB=vcs-svn/lib.a
+LIB_FILE = libgit.a
+XDIFF_LIB = xdiff/lib.a
+VCSSVN_LIB = vcs-svn/lib.a
LIB_H += xdiff/xinclude.h
LIB_H += xdiff/xmacros.h
@@ -1139,7 +1139,7 @@ ifeq ($(uname_S),NetBSD)
endif
ifeq ($(uname_S),AIX)
DEFAULT_PAGER = more
- NO_STRCASESTR=YesPlease
+ NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKDTEMP = YesPlease
NO_MKSTEMPS = YesPlease
@@ -1147,7 +1147,7 @@ ifeq ($(uname_S),AIX)
NO_NSEC = YesPlease
FREAD_READS_DIRECTORIES = UnfortunatelyYes
INTERNAL_QSORT = UnfortunatelyYes
- NEEDS_LIBICONV=YesPlease
+ NEEDS_LIBICONV = YesPlease
BASIC_CFLAGS += -D_LARGE_FILES
ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
NO_PTHREADS = YesPlease
@@ -1155,13 +1155,13 @@ ifeq ($(uname_S),AIX)
PTHREAD_LIBS = -lpthread
endif
ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
- INLINE=''
+ INLINE = ''
endif
GIT_TEST_CMP = cmp
endif
ifeq ($(uname_S),GNU)
# GNU/Hurd
- NO_STRLCPY=YesPlease
+ NO_STRLCPY = YesPlease
NO_MKSTEMPS = YesPlease
HAVE_PATHS_H = YesPlease
LIBC_CONTAINS_LIBINTL = YesPlease
@@ -1187,9 +1187,9 @@ ifeq ($(uname_S),IRIX)
NEEDS_LIBGEN = YesPlease
endif
ifeq ($(uname_S),IRIX64)
- NO_SETENV=YesPlease
+ NO_SETENV = YesPlease
NO_UNSETENV = YesPlease
- NO_STRCASESTR=YesPlease
+ NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKSTEMPS = YesPlease
NO_MKDTEMP = YesPlease
@@ -1203,14 +1203,14 @@ ifeq ($(uname_S),IRIX64)
NO_REGEX = YesPlease
NO_FNMATCH_CASEFOLD = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
- SHELL_PATH=/usr/gnu/bin/bash
+ SHELL_PATH = /usr/gnu/bin/bash
NEEDS_LIBGEN = YesPlease
endif
ifeq ($(uname_S),HP-UX)
INLINE = __inline
- NO_IPV6=YesPlease
- NO_SETENV=YesPlease
- NO_STRCASESTR=YesPlease
+ NO_IPV6 = YesPlease
+ NO_SETENV = YesPlease
+ NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
NO_MKSTEMPS = YesPlease
NO_STRLCPY = YesPlease
@@ -1386,10 +1386,10 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
MKDIR_WO_TRAILING_SLASH = YesPlease
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
- SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
- SHELL_PATH=/usr/local/bin/bash
+ SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
+ SHELL_PATH = /usr/local/bin/bash
# as of H06.25/J06.14, we might better use this
- #SHELL_PATH=/usr/coreutils/bin/bash
+ #SHELL_PATH = /usr/coreutils/bin/bash
endif
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
@@ -1437,7 +1437,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
X = .exe
SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
- htmldir=doc/git/html/
+ htmldir = doc/git/html/
prefix =
INSTALL = /bin/install
EXTLIBS += /mingw/lib/libz.a
@@ -1559,7 +1559,7 @@ else
CURL_LIBCURL = -lcurl
endif
ifdef NEEDS_SSL_WITH_CURL
- CURL_LIBCURL += -lssl
+ CURL_LIBCURL += -lssl
ifdef NEEDS_CRYPTO_WITH_SSL
CURL_LIBCURL += -lcrypto
endif
@@ -1768,7 +1768,7 @@ ifdef OBJECT_CREATION_USES_RENAMES
endif
ifdef NO_STRUCT_ITIMERVAL
COMPAT_CFLAGS += -DNO_STRUCT_ITIMERVAL
- NO_SETITIMER=YesPlease
+ NO_SETITIMER = YesPlease
endif
ifdef NO_SETITIMER
COMPAT_CFLAGS += -DNO_SETITIMER
@@ -1920,15 +1920,15 @@ ifneq (,$(XDL_FAST_HASH))
endif
ifeq ($(TCLTK_PATH),)
-NO_TCLTK=NoThanks
+NO_TCLTK = NoThanks
endif
ifeq ($(PERL_PATH),)
-NO_PERL=NoThanks
+NO_PERL = NoThanks
endif
ifeq ($(PYTHON_PATH),)
-NO_PYTHON=NoThanks
+NO_PYTHON = NoThanks
endif
QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
@@ -1975,13 +1975,13 @@ PROFILE_DIR := $(CURDIR)
ifeq ("$(PROFILE)","GEN")
CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
EXTLIBS += -lgcov
- export CCACHE_DISABLE=t
- V=1
+ export CCACHE_DISABLE = t
+ V = 1
else
ifneq ("$(PROFILE)","")
CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
- export CCACHE_DISABLE=t
- V=1
+ export CCACHE_DISABLE = t
+ V = 1
endif
endif
@@ -2830,7 +2830,7 @@ git.spec: git.spec.in GIT-VERSION-FILE
sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+
mv $@+ $@
-GIT_TARNAME=git-$(GIT_VERSION)
+GIT_TARNAME = git-$(GIT_VERSION)
dist: git.spec git-archive$(X) configure
./git-archive --format=tar \
--prefix=$(GIT_TARNAME)/ HEAD^{tree} > $(GIT_TARNAME).tar
diff --git a/config.mak.in b/config.mak.in
index 69d4838..e8a9bb4 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -18,7 +18,7 @@ datarootdir = @datarootdir@
template_dir = @datadir@/git-core/templates
sysconfdir = @sysconfdir@
-mandir=@mandir@
+mandir = @mandir@
srcdir = @srcdir@
VPATH = @srcdir@
diff --git a/t/Makefile b/t/Makefile
index 88e289f..3025418 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -6,7 +6,7 @@
-include ../config.mak.autogen
-include ../config.mak
-#GIT_TEST_OPTS=--verbose --debug
+#GIT_TEST_OPTS = --verbose --debug
SHELL_PATH ?= $(SHELL)
PERL_PATH ?= /usr/bin/perl
TAR ?= $(TAR)
--
1.8.0.1.347.gf94c325
^ permalink raw reply related
* Re: [PATCH] gitk: read and write a repository specific configuration file
From: Paul Mackerras @ 2012-12-09 10:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Łukasz Stelmach, git, mbranchaud
In-Reply-To: <7vd2yjeg8f.fsf@alter.siamese.dyndns.org>
On Sun, Dec 09, 2012 at 01:18:08AM -0800, Junio C Hamano wrote:
> Łukasz Stelmach <stlman@poczta.fm> writes:
>
> > Enable gitk read and write repository specific configuration
> > file: ".git/k" if the file exists. To make gitk use the local
> > file simply create one, e.g. with the touch(1) command.
> >
> > This is very useful if one uses different views for different
> > repositories. Now there is no need to store all of them in
> > ~/.gitk and make the views list needlessly long.
>
> I do not use gitk heavily myself, but I have a mixed feeling about
> this patch.
I agree, I think this would be surprising to people who are used to
the way gitk works now.
I could imagine having a checkbox in the Edit->Preferences dialog to
say "Save configuration settings locally", and if you check that box,
then it writes the configuration to .git/gitkconfig or whatever
(having first saved that setting in the global ~/.gitk). But I think
it should be an opt-in thing.
> In any case, the filename .git/k may be _cute_, but I do not think
> we would want to see:
>
> $ ls .git
> branches config HEAD index k objects
> COMMIT_EDITMSG description hooks info logs refs
>
> It is too cryptic, unless the user _knows_ 'k' is for gitk. I'd
> call it $GIT_DIR/gitkconfig or something, if I were supportive for
> this feature (which I am not enthusiastic, yet).
I agree with this too.
Paul.
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2012-12-09 11:18 UTC (permalink / raw)
To: Soren Brinkmann; +Cc: Junio C Hamano, git
In-Reply-To: <7d290bdc-8654-4526-ba73-89408fa99a16@DB3EHSMHS002.ehs.local>
>> Hrm, following your discussion (ellided above), I would have
>> expected that you would show
>>
>> Removing directory foo/bar
>> Removing untracked_file1
>
> Also it would be nice to have warnings about undeleted directories since this git
> clean behavior (or the work around to pass -f twice) is not documented.
> Without a warning you would probably miss that something was _not_ deleted.
Thanks for the feedback. I think you're right. Showing 'foo/bar/bar.txt' in
the list when 'foo/bar/' directory has been successfully deleted is just noise.
Would like to get some more feedback on the proposed output in case of
(1) an untracked subdirectory with multiple files where at least one of them
cannot be removed.
(2) reporting ignored untracked git subdirectories
Suppose we have a repo like the one below:
test.git/
|-- tracked_file
|-- untracked_file
|-- untracked_foo/
| |-- bar/
| | |-- bar.txt
| |-- emptydir/
| |-- frotz.git/
| | |-- frotx.txt
| |-- quux/
| |-- failedquux.txt
| |-- quux.txt
|-- untracked_unreadable_dir/
| |-- afile
|-- untracked_some.git/
|-- some.txt
$ git clean -fd
Removing untracked_file
Removing untracked_foo/bar
Removing untracked_foo/emptydir
Removing untracked_foo/quux/quux.txt
warning: failed to remove untracked_foo/quux/failedquux.txt
warning: failed to remove remove untracked_unreadable_dir/
warning: ignoring untracked git repository untracked_foo/frotz.git/
warning: ignoring untracked git repository untracked_some.git/
Use git clean --force --force to delete all untracked git repositories
$ # use forced remove
$ git clean --force --force -d
Removing untracked_foo/frotz.git
Removing untracked_foo/quux/quux.txt
Removing untracked_some.git/
warning: failed to remove untracked_foo/quux/failedquux.txt
warning: failed to remove untracked_unreadable_dir/
Can you see any issues with the proposed output, wording above? If
everyone is happy,
I'm going to prepare patch V2 for it.
Thanks,
Zoltan
^ permalink raw reply
* Re: [PATCH 8/8] t9402: Use TABs for indentation
From: John Szakmeister @ 2012-12-09 11:19 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, git, mmogilvi_git
In-Reply-To: <50C4616D.9010801@web.de>
On Sun, Dec 9, 2012 at 5:01 AM, Torsten Bögershausen <tboegi@web.de> wrote:
[snip]
> PS: for some reason I don't get any mails to my
> (google) account any more, which I use to read the list.
> Am I the only one having this problem?
I noticed that the kernel.org lists are pretty unaccommodating. If
something hiccups in the delivery, it'll drop (or disable?) sending
emails to you. I've got some spam protection on my server that was
causing some issues occasionally when a lookup took to long. I
wouldn't be surprised if a hiccup occurs now and then with gmail, and
the same thing happens.
-John
^ permalink raw reply
* Re: [PATCH] gitk: read and write a repository specific configuration file
From: Lukasz Stelmach @ 2012-12-09 13:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, mbranchaud, paulus
In-Reply-To: <7vd2yjeg8f.fsf@alter.siamese.dyndns.org>
W dniu 09.12.2012 10:18, Junio C Hamano pisze:
> Łukasz Stelmach <stlman@poczta.fm> writes:
>
>> Enable gitk read and write repository specific configuration
>> file: ".git/k" if the file exists. To make gitk use the local
>> file simply create one, e.g. with the touch(1) command.
>>
>> This is very useful if one uses different views for different
>> repositories. Now there is no need to store all of them in
>> ~/.gitk and make the views list needlessly long.
>
> I do not use gitk heavily myself, but I have a mixed feeling about
> this patch.
>
> Forking the configuration from the one true ~/.gitk is easy; it is
> just the matter of copying it to repository specific location. Once
> forked, however, it is very hard to merge these configuration files
> sprinkled across repositories back, or more importantly, change the
> settings globally.
For the record, I assumed someone using git is capable of doing some
simple tricks with find, sed and the like.
Merging configuration from the global file (~/.gitk) is quite easy as
the file is sourced just before the local file. If any option is not set
in the local file the global value is effective.
To handle the case you describe below...
> Imagine you just got a new monitor that is a lot
> finer grained than the one you have been usingq, and your choice of
> font size has been specified in terms of pixels; you would want to
> show all gitk windows in larger font now, regardless of the
> repository, but you now have to go to 47 different configuration
> files and update them.
you need to (assume one keeps git repositoris below $HOME)
1. Enter a random repository
2. mv .git/gitk .git/gitk-local (see below)
3. Run gitk, configure fonts to your taste, save config (it will be
saved globally)
4. mv .git/gitk-local .git/gitk
4 Do a trick
$ find ../ -name gitk -type f -path '*/.git/gitk' -print0 | \
xargs -0 sed -i -e '/^set [a-z]\+font /d'
Now the font settings from ~/.gitk will be applied (and saved locally
when gitk exits) in every repository find(1) found.
> So I suspect that this may introduce more trouble than it is worth
> for users and should not be sold with a "This is very useful" label.
> At best, it is "This may be useful";
I work with more than two dozen different repositories and saving the
list of branches I want to see upon startup is quite important for me.
> otherwise the feature may end
> up harming our users. I'd phrase it without judging if it is good
> or bad for the users, perhaps like this:
>
> This allows one to specify different views for different
> repositories.
At present the code won't harm anyone not willing to get harmed. To make
gitk save the configuration locally user needs to create the
configuration file manually, outside of gitk, for example with touch(1)
(yes it may be empty).
> In any case, the filename .git/k may be _cute_, but I do not think
> we would want to see:
>
> $ ls .git
> branches config HEAD index k objects
> COMMIT_EDITMSG description hooks info logs refs
I agree this was just to draw your attention ;-)
> It is too cryptic, unless the user _knows_ 'k' is for gitk. I'd
> call it $GIT_DIR/gitkconfig or something, if I were supportive for
> this feature (which I am not enthusiastic, yet).
I think simply $GIT_DIR/gitk as in ~/.gitk is going to be fine.
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska. (c)PP
^ permalink raw reply
* Re: [PATCH] gitk: read and write a repository specific configuration file
From: Lukasz Stelmach @ 2012-12-09 13:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: gitster, git, mbranchaud
In-Reply-To: <20121209104426.GA20818@bloggs.ozlabs.ibm.com>
W dniu 09.12.2012 11:44, Paul Mackerras pisze:
> On Sun, Dec 09, 2012 at 01:18:08AM -0800, Junio C Hamano wrote:
>> Łukasz Stelmach <stlman@poczta.fm> writes:
>>
>>> Enable gitk read and write repository specific configuration
>>> file: ".git/k" if the file exists. To make gitk use the local
>>> file simply create one, e.g. with the touch(1) command.
>>>
>>> This is very useful if one uses different views for different
>>> repositories. Now there is no need to store all of them in
>>> ~/.gitk and make the views list needlessly long.
>>
>> I do not use gitk heavily myself, but I have a mixed feeling about
>> this patch.
>
> I agree, I think this would be surprising to people who are used to
> the way gitk works now.
>
> I could imagine having a checkbox in the Edit->Preferences dialog to
> say "Save configuration settings locally", and if you check that box,
> then it writes the configuration to .git/gitkconfig or whatever
> (having first saved that setting in the global ~/.gitk).
No this isn't a good idea. When you choose to save configuration locally
it means you've alredy changed it to match your local needs and making
it global does not seem reasonable.
> But I think it should be an opt-in thing.
It is opt-in now definitely. One needs to create the local config file,
even an empty one, for gitk to choose it upon doquit/savestuff. I agree
a checkbox may be more convenient but is it "opty" (as in opt-in) enough?
Then, the checkbox should be added to both "Preferences" and "Edit View"
dialogs, anything more?
>> In any case, the filename .git/k may be _cute_, but I do not think
>> we would want to see:
>>
>> $ ls .git
>> branches config HEAD index k objects
>> COMMIT_EDITMSG description hooks info logs refs
>>
>> It is too cryptic, unless the user _knows_ 'k' is for gitk. I'd
>> call it $GIT_DIR/gitkconfig or something, if I were supportive for
>> this feature (which I am not enthusiastic, yet).
>
> I agree with this too.
Sure, let's vote:
a) .git/gitk
b) .git/gitkconfig
c) .git/gitkrc
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska. (c)PP
^ permalink raw reply
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Nguyen Thai Ngoc Duy @ 2012-12-09 13:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3sthhfy.fsf@alter.siamese.dyndns.org>
On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * If somebody has a working replacement URL, we could use that
>> instead, of course. Takers?
>
> A possible alternative could be https://www.ohloh.net/p/git/contributors/summary
Nice charts!
--
Duy
^ permalink raw reply
* Re: Weird problem with git-submodule.sh
From: Stefano Lattarini @ 2012-12-09 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Branchaud, Git Mailing List
In-Reply-To: <7vobi5fu3c.fsf@alter.siamese.dyndns.org>
Hi Junio, Marc.
On 12/07/2012 10:08 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to
>> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.
>
> Finally. Yes, as you suspected, I am perfectly fine to explicitly
> set IFS to the default values.
>
> I wanted to have specific names to write in the commit log message,
> in-code comments and possibly release notes. That way, people can
> decide if the issue affects them and they should upgrade once the
> fix is made.
>
The Autoconf manual suggests against unsetting IFS instead of resetting
it to the default sequence for yet another reason: if IFS is unset, code
that tries to save and restore its value will incorrectly reset it to an
empty value, thus disabling field splitting:
unset IFS
# default separators used for field splitting
# ...
saved_IFS=$IFS
IFS=:
# code using the new IFS
IFS=$saved_IFS
# no field splitting performed from now on!
Not sure how this is relevant for the Git codebase, but maybe it is
something worth reporting in the commit message of a proposed patch.
Regards,
Stefano
^ permalink raw reply
* exit code from git reset
From: Martin von Zweigbergk @ 2012-12-09 22:23 UTC (permalink / raw)
To: git
Hi,
"git reset" currently returns 0 (if successful) while "git reset
$pathspec" returns 0 iff the index matches HEAD after resetting (on
all paths, not just those matching $pathspec). The exit code doesn't
seem to be documented. Is there a reason they should behave
differently? If not, what would be the better behavior? I don't see
when the "git reset $pathspec" behavior" would be useful and it seems
safer for any existing scripts out there not to change the status code
for "git reset" (w/o paths). Scripts that run "git reset $pathspec"
probably already know to ignore (or use?) the exit code. Also, having
any non-zero exit code signal failure might actually be useful.
Changing "git reset $pathspec" to return 0 on success, regardless of
diff between HEAD and index, breaks 10 test cases (in
t2013-checkout-submodule.sh and t7102-reset.sh). These seem to do
"test_must_fail git reset $pathspec", but I have not been able to find
any motivation for expecting the failure.
It seems like this behavior has been there at least since the tests
were added in 359048d (Add tests for documented features of "git
reset"., 2007-09-11), just before reset became built-in.
Would a patch to change the exit code from "git reset $pathspec" be appreciated?
Martin
^ permalink raw reply
* RE: Feature Request - Hide ignored files before checkout
From: Matthew Ciancio @ 2012-12-09 22:37 UTC (permalink / raw)
To: 'Junio C Hamano'; +Cc: git, 'Chris Rorvick'
In-Reply-To: <7vhanvegvu.fsf@alter.siamese.dyndns.org>
I appreciate your involvement, Mr Hamano.
You have made me realise that my intentions were flawed from the beginning,
because I had been misusing the branch feature.
Thank you for your time.
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Sunday, 9 December 2012 8:04 PM
To: Chris Rorvick
Cc: Matthew Ciancio; git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout
Chris Rorvick <chris@rorvick.com> writes:
> It's not in branchA, it's just no longer ignored because your changes
> to .gitignore were effectively reverted by jumping back to the commit
> that branchA points to.
> ...
> "hide/reappear" is the equivalent to saying "deleted/created" in the
> case of a tracked file in your working tree. But how would Git cause
> an untracked file to reappear? By definition, it doesn't know
> anything about the file.
Nicely explained. To make something simply disappear, you could remove it,
but that is obviously not enough to make it reappear. It has to be stashed
away somewhere before it gets removed, and in the context of (any) SCM, that
is done by committing.
You may have Mac and Windows branches, each of which needs to link with
vendor supplied object file blackbox.o with the rest of the source. It is
understandable if a project does not want to mix such platform specific
black box binaries in the history of the source.
But that does not necessarily mean the project can totally ignore what
specific black box binary was meant to be used with the rest of the source.
After you released the v1.0 of your product for both Macintosh and Windows,
the vendor may supply updated versions of the blackbox.o binary for these
platforms, and you would start working toward v1.1 of your product using
these updated copies of objects. Then you find problems in the released
v1.0 software. Without keeping track of which version of the object was
used to build the released v1.0, you cannot diagnose, build and test a
maintenance update v1.0.1.
The project may add new Macintosh (or Windows) developers. You can tell new
Macintosh developers to clone and checkout mac branch, and in the same
e-mail, give them the untracked blackbox.o file for that platform, but you
have to rely on human not making mistakes (you may mistakenly send Windows
version of blackbox.o to him, you may send stale Macintosh version, the
developer may misplace the new one and keep using the stale one, etc. etc.).
Some people commit blackbox.o on each platform-specific branch, or all
branches share blackbox-win.o and blackbox-mac.o, only one of which is used
at any given branch, for this exact reason.
The project, for licensing reasons, may not have rights to distribute such a
blackbox object file along with its sources, but the vendor of the blackbox
object may allow individual developer to download and link it from vendor's
site. In such a case, the project would not want to (and is not allowed to)
commit such object file. One approach I have seen used in such a case is to
arrange the build procedure so that these individual developers can drop
such an external object next to the project directory, and refer to it as
../blackbox.o when linking.
So "these files are moved away from the working tree upon checking another
branch out, and moved back into the working tree upon checking out this
branch" is pretty much outside the scope of any SCM. It is not very
interesting, as it is not necessary to solve any real world problem.
Of course, the users can do whatever moving/copying/renaming of untracked
files in their post-checkout hook to be run when a new branch is checked
out.
^ permalink raw reply
* Re: exit code from git reset
From: Junio C Hamano @ 2012-12-09 23:04 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6i0LXE18Pyb5norRTm7PM+TMo3JvxDjoS5JOWt_qjHLHw@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> "git reset" currently returns 0 (if successful) while "git reset
> $pathspec" returns 0 iff the index matches HEAD after resetting (on
> all paths, not just those matching $pathspec).
So in short, you observed that either of them reports with its exit
code if the resulting index (not just any subpart, but always the
entire thing) matches the HEAD, e.g. "do we have change that will be
listed on 'will be committed' section in git status output?"
Sounds like one sane and consistent semantics to me. I am not
saying that there cannot be other behaviours that are internally
consistent (e.g. the error code could have matched the number of
paths that are different between the index and the HED, or the error
code could have been zero for successful reset, non-zero for some
failure), but I am saying that the current behaviour gives _one_
sane and consistent meanings regardless of how you ran the command.
> The exit code doesn't seem to be documented.
Please make it so.
> Changing "git reset $pathspec" to return 0 on success, regardless of
> diff between HEAD and index, breaks 10 test cases (in
> t2013-checkout-submodule.sh and t7102-reset.sh). These seem to do
> "test_must_fail git reset $pathspec", but I have not been able to find
> any motivation for expecting the failure.
See above.
^ permalink raw reply
* Re: exit code from git reset
From: Martin von Zweigbergk @ 2012-12-09 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzk1mddzo.fsf@alter.siamese.dyndns.org>
On Sun, Dec 9, 2012 at 3:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>> "git reset" currently returns 0 (if successful) while "git reset
>> $pathspec" returns 0 iff the index matches HEAD after resetting (on
>> all paths, not just those matching $pathspec).
>
> So in short, you observed that either of them reports with its exit
> code if the resulting index (not just any subpart, but always the
> entire thing) matches the HEAD, e.g. "do we have change that will be
> listed on 'will be committed' section in git status output?"
>
> Sounds like one sane and consistent semantics to me.
Heh, true, the behavior according to my description does make sense,
it's just that my description was wrong; sorry :-(.
What "git reset $pathspec" returns is not "whether HEAD differs from
index" (as I wrote), but "whether worktree differs from index". So
"git reset" and "git reset ." will return different exit codes if
there are changes in the worktree as compared to HEAD before the
invocation. I hope that's clearer.
^ permalink raw reply
* Re: Feature Request - Hide ignored files before checkout
From: Andrew Ardill @ 2012-12-10 1:46 UTC (permalink / raw)
To: Matthew Ciancio; +Cc: git@vger.kernel.org
In-Reply-To: <000301cdd4dd$f8554090$e8ffc1b0$@gmail.com>
Hi Matt,
On 8 December 2012 11:50, Matthew Ciancio <matthew.ciancio16@gmail.com> wrote:
> Problem: ignore.txt does not "disappear" like foo.txt does and is now just
> sitting in branchA (and now any other branch I checkout into).
>
> When I first started using Git, I genuinely thought this was a bug, because
> it seems so logical to me that ignore files should hide/reappear just like
> tracked files do, when switching branches.
Let me address this by asking a few questions; *why* do files
hide/reappear, what is the mechanism behind that and does it really
make sense to apply it to ignored files.
For each commit, git stores a snapshot of your files. When we switch
branches we are telling git to restore the previously saved snapshot
so we can work with those files. This means resetting the working
directory so that it looks like what we had committed; git will delete
files that were part of the current checked out snapshot but not the
new one, and create files that need to be created. As a convenience to
users, files that are not tracked are left 'as-is' when switching
branches.
So we see that in order to hide/reappear a file it has to be tracked
in a snapshot, and so has to be committed *somewhere*. An ignored file
is by definition not included in commits, and furthermore you hope to
keep these files out of your commit history.
> I have been told ways of circumventing this (using commits and un-commits OR
> using stash), but my reason for avoiding commits is: say you have binary/OS
> specific files which really do not belong in the commit logs (even locally)
> and hence should be ignored. What if you want those files in only one branch
> and not all?
> Stashing doesn't seem appropriate either, because it would get messy.
I am not sure how viable a suggestion this is, but perhaps you can
have two separate repositories, one tracking your standard branches,
and another tracking the ignored files. These repositories could be
kept in sync through submodules or some similar mechanism. This could
also allow you to, for example, publish the histories of these
independently, for example releasing the non-ignored repository
publicly.
I haven't heard of anyone doing this, but if you need to keep the
history clean it might be a way of achieving it.
I also don't know what the implications of checking out two
repositories into the same tree might be, or even if git would allow
it in general (maybe if you ignored everything belonging to the other
repository?) In any case, this solution could quickly become messy,
but if carefully controlled might solve your problem. Then again,
maybe you can achieve what you want using more 'traditional' git
workflows.
Regards,
Andrew Ardill
^ 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