[PATCH v6 3/7] add tests for rebasing of empty commits
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3401-rebase-partial.sh | 24
t/t3421-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 58f4823..7ba1797 100755
--- a/t/t3401-rebase-partial.sh
+++ b/t/t3401-rebase-partial.sh
@@ -42,28 +42,4 @@ test_expect_success 'rebase --merge topic branch that was
partially merged upstr
test_path_is_missing .git/rebase-merge
'
-test_expect_success 'rebase ignores empty commit' '
- git reset --hard A
- git commit --allow-empty -m empty
- test_commit D
- git rebase C
- test $(git log --format=%s C..) = D
-'
-
-test_expect_success 'rebase --keep-empty' '
- git reset --hard D
- git rebase --keep-empty C
- test $(git log --format=%s C..) = D
-empty
-'
-
-test_expect_success 'rebase --keep-empty keeps empty even if already in
upstream' '
- git reset --hard A
- git commit --allow-empty -m also-empty
- git rebase --keep-empty D
- test $(git log --format=%s A..) = also-empty
-D
-empty
-'
-
test_done
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index ddcbfc6..f19f0d0 100755
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -160,4 +160,62 @@ test_run_rebase success -m
test_run_rebase success -i
test_run_rebase success -p
+# a---b---c---j!
+# \
+# d---k!--l
+#
+# ! = empty
+test_expect_success 'setup of linear history for empty commit tests' '
+ git checkout c
+ make_empty j
+ git checkout d
+ make_empty k
+ test_commit l
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* drops empty commit
+ reset_rebase
+ git rebase $* c l
+ test_cmp_rev c HEAD~2
+ test_linear_range 'd l' c..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --keep-empty
+ reset_rebase
+ git rebase $* --keep-empty c l
+ test_cmp_rev c HEAD~3
+ test_linear_range 'd k l' c..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --keep-empty keeps empty even if already
in upstream
+ reset_rebase
+ git rebase $* --keep-empty j l
+ test_cmp_rev j HEAD~3
+ test_linear_range 'd k l' j..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase failure -i
+test_run_rebase failure -p
+
test_done
--
1.8.3.497.g83fddbe
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/7] add tests for rebasing with patch-equivalence present
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/lib-rebase.sh | 17
t/t3421-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 1e0ff28..4b74ae4 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -81,3 +81,20 @@ reset_rebase () {
git reset --hard
git clean -f
}
+
+cherry_pick () {
+ git cherry-pick -n $2
+ git commit -m $1
+ git tag $1
+}
+
+revert () {
+ git revert -n $2
+ git commit -m $1
+ git tag $1
+}
+
+make_empty () {
+ git commit --allow-empty -m $1
+ git tag $1
+}
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index 60365d1..ddcbfc6 100755
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -75,4 +75,89 @@ test_run_rebase success -m
test_run_rebase success -i
test_run_rebase success -p
+# f
+# /
+# a---b---c---g---h
+# \
+# d---G---i
+#
+# uppercase = cherry-picked
+# h = reverted g
+#
+# Reverted patches are there for tests to be able to check if a commit
+# that introduced the same change as another commit is
+# dropped. Without reverted commits, we could get false positives
+# because applying the patch succeeds, but simply results in no
+# changes.
+test_expect_success 'setup of linear history for range selection tests' '
+ git checkout c
+ test_commit g
+ revert h g
+ git checkout d
+ cherry_pick G g
+ test_commit i
+ git checkout b
+ test_commit f
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* drops patches in upstream
+ reset_rebase
+ git rebase $* h i
+ test_cmp_rev h HEAD~2
+ test_linear_range 'd i' h..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* can drop last patch if in upstream
+ reset_rebase
+ git rebase $* h G
+ test_cmp_rev h HEAD^
+ test_linear_range 'd' h..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto drops patches in upstream
+ reset_rebase
+ git rebase $* --onto f h i
+ test_cmp_rev f HEAD~2
+ test_linear_range 'd i' f..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto does not drop patches in onto
+ reset_rebase
+ git rebase $* --onto h f i
+ test_cmp_rev h HEAD~3
+ test_linear_range 'd G i' h..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
test_done
--
1.8.3.497.g83fddbe
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/7] add simple tests of consistency across rebase types
Helped-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/lib-rebase.sh | 16
t/t3421-rebase-topology-linear.sh | 78 +++
2 files changed, 94 insertions(+)
create mode 100755 t/t3421-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 6ccf797..1e0ff28 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -65,3 +65,19 @@ EOF
test_set_editor $(pwd)/fake-editor.sh
chmod a+x fake-editor.sh
}
+
+# checks that the revisions in $2 represent a linear range with the
+# subjects in $1
+test_linear_range () {
+ revlist_merges=$(git rev-list --merges $2)
+ test -z $revlist_merges
+ expected=$1
+ set -- $(git log --reverse --format=%s $2)
+ test $expected = $*
+}
+
+reset_rebase () {
+ test_might_fail git rebase --abort
+ git reset --hard
+ git clean -f
+}
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
new file mode 100755
index 000..60365d1
--- /dev/null
+++ b/t/t3421-rebase-topology-linear.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+
+test_description='basic rebase topology tests'
+. ./test-lib.sh
+. $TEST_DIRECTORY/lib-rebase.sh
+
+# a---b---c
+# \
+# d---e
+test_expect_success 'setup' '
+ test_commit a
+ test_commit b
+ test_commit c
+ git checkout b
+ test_commit d
+ test_commit e
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result simple rebase $*
+ reset_rebase
+ git rebase $* c e
+ test_cmp_rev c HEAD~2
+ test_linear_range 'd e' c..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* is no-op if upstream is an ancestor
+ reset_rebase
+ git rebase $* b e
+ test_cmp_rev e HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* -f rewrites even if upstream is an
ancestor
+ reset_rebase
+ git rebase $* -f b e
+ ! test_cmp_rev e HEAD
+ test_cmp_rev b HEAD~2
+ test_linear_range 'd e' b..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* fast-forwards from ancestor of upstream
+ reset_rebase
+ git rebase $* e b
+ test_cmp_rev e HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_done
--
1.8.3.497.g83fddbe
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 7/7] tests: move test for rebase messages from t3400 to t3406
t3406 is supposed to test messages from rebase operation, so let's move tests in t3400 that fit that description into 3406. Most of the functionality they tested, except for the messages, has now been subsumed by t3420. Signed-off-by: Martin von Zweigbergk martinv...@gmail.com --- t/t3400-rebase.sh | 22 -- t/t3406-rebase-message.sh | 22 ++ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh index b436ef4..45a55e9 100755 --- a/t/t3400-rebase.sh +++ b/t/t3400-rebase.sh @@ -59,28 +59,6 @@ test_expect_success 'rebase against master' ' git rebase master ' -test_expect_success 'rebase against master twice' ' - git rebase master out - test_i18ngrep Current branch my-topic-branch is up to date out -' - -test_expect_success 'rebase against master twice with --force' ' - git rebase --force-rebase master out - test_i18ngrep Current branch my-topic-branch is up to date, rebase forced out -' - -test_expect_success 'rebase against master twice from another branch' ' - git checkout my-topic-branch^ - git rebase master my-topic-branch out - test_i18ngrep Current branch my-topic-branch is up to date out -' - -test_expect_success 'rebase fast-forward to master' ' - git checkout my-topic-branch^ - git rebase my-topic-branch out - test_i18ngrep Fast-forwarded HEAD to my-topic-branch out -' - test_expect_success 'the rebase operation should not have destroyed author information' ' ! (git log | grep Author: | grep ) ' diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh index fe8c27f..0392e36 100755 --- a/t/t3406-rebase-message.sh +++ b/t/t3406-rebase-message.sh @@ -30,6 +30,28 @@ test_expect_success 'rebase -m' ' test_cmp expect actual ' +test_expect_success 'rebase against master twice' ' + git rebase master out + test_i18ngrep Current branch topic is up to date out +' + +test_expect_success 'rebase against master twice with --force' ' + git rebase --force-rebase master out + test_i18ngrep Current branch topic is up to date, rebase forced out +' + +test_expect_success 'rebase against master twice from another branch' ' + git checkout topic^ + git rebase master topic out + test_i18ngrep Current branch topic is up to date out +' + +test_expect_success 'rebase fast-forward to master' ' + git checkout topic^ + git rebase topic out + test_i18ngrep Fast-forwarded HEAD to topic out +' + test_expect_success 'rebase --stat' ' git reset --hard start git rebase --stat master diffstat.txt -- 1.8.3.497.g83fddbe -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/7] add tests for rebasing root
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3421-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index f19f0d0..e67add6 100755
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -218,4 +218,133 @@ test_run_rebase failure -m
test_run_rebase failure -i
test_run_rebase failure -p
+# m
+# /
+# a---b---c---g
+#
+# x---y---B
+#
+# uppercase = cherry-picked
+# m = reverted b
+#
+# Reverted patches are there for tests to be able to check if a commit
+# that introduced the same change as another commit is
+# dropped. Without reverted commits, we could get false positives
+# because applying the patch succeeds, but simply results in no
+# changes.
+test_expect_success 'setup of linear history for test involving root' '
+ git checkout b
+ revert m b
+ git checkout --orphan disjoint
+ git rm -rf .
+ test_commit x
+ test_commit y
+ cherry_pick B b
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto --root
+ reset_rebase
+ git rebase $* --onto c --root y
+ test_cmp_rev c HEAD~2
+ test_linear_range 'x y' c..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* without --onto --root with disjoint
history
+ reset_rebase
+ git rebase $* c y
+ test_cmp_rev c HEAD~2
+ test_linear_range 'x y' c..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto --root drops patch in onto
+ reset_rebase
+ git rebase $* --onto m --root B
+ test_cmp_rev m HEAD~2
+ test_linear_range 'x y' m..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto --root with merge-base does not
go to root
+ reset_rebase
+ git rebase $* --onto m --root g
+ test_cmp_rev m HEAD~2
+ test_linear_range 'c g' m..
+
+}
+
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* without --onto --root with disjoint
history drops patch in onto
+ reset_rebase
+ git rebase $* m B
+ test_cmp_rev m HEAD~2
+ test_linear_range 'x y' m..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --root on linear history is a no-op
+ reset_rebase
+ git rebase $* --root c
+ test_cmp_rev c HEAD
+
+}
+test_run_rebase failure ''
+test_run_rebase failure -m
+test_run_rebase failure -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* -f --root on linear history causes
re-write
+ reset_rebase
+ git rebase $* -f --root c
+ ! test_cmp_rev a HEAD~2
+ test_linear_range 'a b c' HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
test_done
--
1.8.3.497.g83fddbe
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/7] t3406: modernize style
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3406-rebase-message.sh | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh
index e6a9a0d..fe8c27f 100755
--- a/t/t3406-rebase-message.sh
+++ b/t/t3406-rebase-message.sh
@@ -4,27 +4,17 @@ test_description='messages from rebase operation'
. ./test-lib.sh
-quick_one () {
- echo $1 file$1
- git add file$1
- test_tick
- git commit -m $1
-}
+test_expect_success 'setup' '
+ test_commit O fileO
+ test_commit X fileX
+ test_commit A fileA
+ test_commit B fileB
+ test_commit Y fileY
-test_expect_success setup '
- quick_one O
- git branch topic
- quick_one X
- quick_one A
- quick_one B
- quick_one Y
-
- git checkout topic
- quick_one A
- quick_one B
- quick_one Z
+ git checkout -b topic O
+ git cherry-pick A B
+ test_commit Z fileZ
git tag start
-
'
cat expect \EOF
@@ -34,12 +24,10 @@ Committed: 0003 Z
EOF
test_expect_success 'rebase -m' '
-
git rebase -m master report
sed -n -e /^Already applied: /p \
-e /^Committed: /p report actual
test_cmp expect actual
-
'
test_expect_success 'rebase --stat' '
--
1.8.3.497.g83fddbe
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/8] Rebase topology test
Changes since v5: * Improved test_linear_range * Changed TODOs to be about consistency, not --topo-order Martin von Zweigbergk (7): add simple tests of consistency across rebase types add tests for rebasing with patch-equivalence present add tests for rebasing of empty commits add tests for rebasing root add tests for rebasing merged history t3406: modernize style tests: move test for rebase messages from t3400 to t3406 t/lib-rebase.sh | 33 t/t3400-rebase.sh | 53 +- t/t3401-rebase-partial.sh | 69 t/t3404-rebase-interactive.sh | 10 +- t/t3406-rebase-message.sh | 50 +++--- t/t3409-rebase-preserve-merges.sh | 53 -- t/t3421-rebase-topology-linear.sh | 350 ++ t/t3425-rebase-topology-merges.sh | 258 8 files changed, 673 insertions(+), 203 deletions(-) delete mode 100755 t/t3401-rebase-partial.sh create mode 100755 t/t3421-rebase-topology-linear.sh create mode 100755 t/t3425-rebase-topology-merges.sh -- 1.8.3.497.g83fddbe -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/7] add tests for rebasing merged history
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com --- t/t3400-rebase.sh | 31 + t/t3401-rebase-partial.sh | 45 --- t/t3404-rebase-interactive.sh | 10 +- t/t3409-rebase-preserve-merges.sh | 53 t/t3425-rebase-topology-merges.sh | 258 ++ 5 files changed, 260 insertions(+), 137 deletions(-) delete mode 100755 t/t3401-rebase-partial.sh create mode 100755 t/t3425-rebase-topology-merges.sh diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh index b58fa1a..b436ef4 100755 --- a/t/t3400-rebase.sh +++ b/t/t3400-rebase.sh @@ -40,13 +40,6 @@ test_expect_success 'prepare repository with topic branches' ' echo Side C git add C git commit -m Add C - git checkout -b nonlinear my-topic-branch - echo Edit B - git add B - git commit -m Modify B - git merge side - git checkout -b upstream-merged-nonlinear - git merge master git checkout -f my-topic-branch git tag topic ' @@ -106,31 +99,9 @@ test_expect_success 'rebase from ambiguous branch name' ' git rebase master ' -test_expect_success 'rebase after merge master' ' - git checkout --detach refs/tags/topic - git branch -D topic - git reset --hard topic - git merge master - git rebase master - ! (git show | grep ^Merge:) -' - -test_expect_success 'rebase of history with merges is linearized' ' - git checkout nonlinear - test 4 = $(git rev-list master.. | wc -l) - git rebase master - test 3 = $(git rev-list master.. | wc -l) -' - -test_expect_success 'rebase of history with merges after upstream merge is linearized' ' - git checkout upstream-merged-nonlinear - test 5 = $(git rev-list master.. | wc -l) - git rebase master - test 3 = $(git rev-list master.. | wc -l) -' - test_expect_success 'rebase a single mode change' ' git checkout master + git branch -D topic echo 1 X git add X test_tick diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh deleted file mode 100755 index 7ba1797..000 --- a/t/t3401-rebase-partial.sh +++ /dev/null @@ -1,45 +0,0 @@ -#!/bin/sh -# -# Copyright (c) 2006 Yann Dirson, based on t3400 by Amos Waterland -# - -test_description='git rebase should detect patches integrated upstream - -This test cherry-picks one local change of two into master branch, and -checks that git rebase succeeds with only the second patch in the -local branch. -' -. ./test-lib.sh - -test_expect_success 'prepare repository with topic branch' ' - test_commit A - git checkout -b my-topic-branch - test_commit B - test_commit C - git checkout -f master - test_commit A2 A.t -' - -test_expect_success 'pick top patch from topic branch into master' ' - git cherry-pick C - git checkout -f my-topic-branch -' - -test_debug ' - git cherry master - git format-patch -k --stdout --full-index master /dev/null - gitk --all sleep 1 -' - -test_expect_success 'rebase topic branch against new master and check git am did not get halted' ' - git rebase master - test_path_is_missing .git/rebase-apply -' - -test_expect_success 'rebase --merge topic branch that was partially merged upstream' ' - git reset --hard C - git rebase --merge master - test_path_is_missing .git/rebase-merge -' - -test_done diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index a58406d..ffcaf02 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -477,19 +477,11 @@ test_expect_success 'interrupted squash works as expected (case 2)' ' test $one = $(git rev-parse HEAD~2) ' -test_expect_success 'ignore patch if in upstream' ' - HEAD=$(git rev-parse HEAD) - git checkout -b has-cherry-picked HEAD^ +test_expect_success '--continue tries to commit, even for edit' ' echo unrelated file7 git add file7 test_tick git commit -m unrelated change - git cherry-pick $HEAD - EXPECT_COUNT=1 git rebase -i $HEAD - test $HEAD = $(git rev-parse HEAD^) -' - -test_expect_success '--continue tries to commit, even for edit' ' parent=$(git rev-parse HEAD^) test_tick FAKE_LINES=edit 1 git rebase -i HEAD^ diff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh index 6de4e22..2e0c364 100755 --- a/t/t3409-rebase-preserve-merges.sh +++ b/t/t3409-rebase-preserve-merges.sh @@ -11,14 +11,6 @@ Run git rebase -p and check that merges are properly carried along GIT_AUTHOR_EMAIL=bogus_email_address export GIT_AUTHOR_EMAIL -# Clone 1 (trivial merge): -# -# A1--A2 -- origin/master -# \ \ -# B1--M -- topic -#\ -# B2 -- origin/topic -# # Clone 2 (conflicting merge): # # A1--A2--B3 -- origin/master
Re: [PATCH] t0005: skip signal death exit code test on Windows
Am 6/6/2013 19:40, schrieb Jeff King:
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
The particular deficiency is that when a signal is raise()d whose SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
After a bit of web searching, it seems to me that this behaviour of
raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls
that. In other words, the implementation of raise() is at an even
lower level than mingw/msys, and I would agree that it is a platform
issue.
Yeah, if it were mingw_raise responsible for this, I would suggest using
the POSIX shell 128+sig instead. We could potentially check for
SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if
that would create headaches or confusion for other msys programs,
though. I'd leave that up to the msysgit people to decide whether it is
worth the trouble.
Even if we move the signal emulation closer to POSIX in the way that you
suggested (if that were possible, I haven't checked), the emulation is
still not complete, because we would have addressed only raise().
Therefore, personally I would like to delay the issue until there is a
user (script) that depends on POSIXly exit codes.
As far as t0005.2 is concerned, its the best to just concede that Windows
does not have POSIX-like behavior as far as signals are concerned, and
skip the test.
We could also sweep the issue under the rug with the patch below, which
works because SIGALRM does not exist in MSVCRT and is handled entirely by
compat/mingw.c. But it goes into the wrong direction, IMO.
diff --git a/t/t0005-signals.sh b/t/t0005-signals.sh
index ad9e604..68b6c3b 100755
--- a/t/t0005-signals.sh
+++ b/t/t0005-signals.sh
@@ -12,9 +12,8 @@ EOF
test_expect_success 'sigchain works' '
test-sigchain actual
case $? in
- 143) true ;; # POSIX w/ SIGTERM=15
- 271) true ;; # ksh w/ SIGTERM=15
- 3) true ;; # Windows
+ 142) true ;; # POSIX w/ SIGALRM=14
+ 270) true ;; # ksh w/ SIGTERM=14
*) false ;;
esac
test_cmp expect actual
@@ -23,8 +22,8 @@ test_expect_success 'sigchain works' '
test_expect_success 'signals are propagated using shell convention' '
# we use exec here to avoid any sub-shell interpretation
# of the exit code
- git config alias.sigterm !exec test-sigchain
- test_expect_code 143 git sigterm
+ git config alias.sigalrm !exec test-sigchain
+ test_expect_code 142 git sigalrm
'
test_done
diff --git a/test-sigchain.c b/test-sigchain.c
index 42db234..0233a39 100644
--- a/test-sigchain.c
+++ b/test-sigchain.c
@@ -14,9 +14,9 @@ X(three)
#undef X
int main(int argc, char **argv) {
- sigchain_push(SIGTERM, one);
- sigchain_push(SIGTERM, two);
- sigchain_push(SIGTERM, three);
- raise(SIGTERM);
+ sigchain_push(SIGALRM, one);
+ sigchain_push(SIGALRM, two);
+ sigchain_push(SIGALRM, three);
+ raise(SIGALRM);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is there a fast web-interface to git for huge repos?
On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote: I'm interested in running a web interface to this and other similar git repositories (FreeBSD and NetBSD git repositories are even much, much bigger). Software-wise, is there no way to make cold access for git-log and git-blame to be orders of magnitude less than ~5s, and warm access less than ~0.5s? The obvious way would be to cache the results. You can even put an update cache hook the git repositories to make the cache always be up to date. There's some dynamic web frontends like cgit and gitweb out there but there's also static ones like git-arr ( http://blitiri.com.ar/p/git-arr/ ) that might be more of an option to you. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git stash while pending merge should not be allowed
A colleague of mine who is well-intentioned and fairly knowledgeable about git recently caused havoc with our repository while merging changes on the main line branch into a feature branch. The reason is that, along the way, he tried to use git stash while the merge was pending. A few commands later, this severely polluted the history of all the files involved. The command sequence started as follows: $ git checkout feature-branch $ git merge mainline-branch (conflicts; merge pending) $ git mergetool (resolve all conflicts; takes a while as there are many) $ make make testsuite (oops, tests don't pass) At this point, the user notices that the fix to the tests is in the next commit on mainline-branch, which wasn't present when it was first merged. Not wanting to have a commit in the history whose tests do not pass, and not wanting to redo all the conflict resolution work involved in starting over with a different merge parent, he tries to cherry pick it: $ git fetch $ git cherry-pick commit-with-fix (error: can't cherry pick while merge pending) Ok, he thinks, git stash has worked in the past as a way to temporarily move aside some work in progress. So: $ git stash $ git cherry-pick commit-with-fix $ git stash pop All seems well, so: $ git commit Unfortunately, this does *not* do what was intended. You see, unbeknownst to this developer, git stash does not save the MERGE_HEAD! So the commit shows up as an enormous single-parent commit on top of feature-branch, referring to none of the merged commits from mainline-branch in its ancestry. Consequently, git annotate and friends regard all the merged changes as having been made by the developer alone and all at once, distorting the file histories to the point of being nearly useless. Furthermore, git still doesn't think mainline-branch has been merged, so there is more fun to be had sorting that out when the next merge from mainline happens. We are now in the middle of an expensive and risky project to repair the damage, since people pulled and pushed afterward, before the problem was noticed. I suggest that this problem could easily have been avoided if git stash refused to run with a pending merge (present MERGE_HEAD file), since this is crucial repository state that it does not save. This seems similar to what git cherry-pick does. -Scott -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
REQUEST-PULL: some msysgit build patches for upstream
The following changes since commit b5c26758639cd934780620d4dd16854c8fdf8c34: Sync with maint (2013-06-03 13:00:09 -0700) are available in the git repository at: http://github.com/msysgit/git tags/post183-for-junio for you to fetch changes up to 65db0443710f59a1c05a85688cdccc215ff48333: Set the default help format to html for msys builds. (2013-06-04 10:12:32 +0100) Collected msysgit build patches for upstream This set of patches collects a number of build fixes that have been used on the msysgit port for a while and merging upstream should simplify future maintenance. Johannes Schindelin (2): Define NO_GETTEXT for Git for Windows Windows resource: handle dashes in the Git version gracefully Pat Thoyts (3): Provide a Windows version resource for the git executables. Ensure the resource file is rebuilt when the version changes. Set the default help format to html for msys builds. Pierre le Riche (1): msysgit: Add the --large-address-aware linker directive to the makefile. Sebastian Schuberth (1): Makefile: Do not use OLD_ICONV on MINGW anymore .gitignore | 1 + Makefile | 8 +++- config.mak.uname | 6 +- git.rc | 22 ++ 4 files changed, 35 insertions(+), 2 deletions(-) create mode 100644 git.rc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Follow perlcritic's recommendations - level 5 and 4
Célestin Matte celestin.ma...@ensimag.fr writes: Subject: [PATCH 01/18] Follow perlcritic's recommendations - level 5 and 4 It would be better to prefix commit messages with git-remote-mediawiki: . Fix warnings from perlcritic's level 5 and 4. It would be cool to have a make perlcritic target in the Makefile so that future developers can easily re-run it and avoid repeating the same mistakes. As much as possible, make perlcritic should produce no output at the end of your patch series (either the warnings should be fixed, or they should be disabled). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/18] Explicitely assign local variable as undef and make a proper one-instruction-by- line indentation
Célestin Matte celestin.ma...@ensimag.fr writes: Subject: [PATCH 08/18] Explicitely assign local variable as undef and make a proper one-instruction-by- line indentation Try to keep short subject lines. We usually consider that 80 character is a strict maximum, and to have e.g. git log --oneline's output fit on 80 column terminal, we try to stick to 50 chars (man git-commit documents that). The subject line can say what the patch does, and the why can be deferred to the body (after the blank line in the commit message). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net wrote: On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote: The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() just calls exit(3). After a bit of web searching, it seems to me that this behaviour of raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls that. In other words, the implementation of raise() is at an even lower level than mingw/msys, and I would agree that it is a platform issue. Yeah, if it were mingw_raise responsible for this, I would suggest using the POSIX shell 128+sig instead. We could potentially check for SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if that would create headaches or confusion for other msys programs, though. I'd leave that up to the msysgit people to decide whether it is worth the trouble. ...and here's the code to do just that: diff --git a/compat/mingw.c b/compat/mingw.c index b295e2f..8b3c1b4 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1573,7 +1573,8 @@ static HANDLE timer_event; static HANDLE timer_thread; static int timer_interval; static int one_shot; -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL; +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL, +sigterm_fn = SIG_DFL; /* The timer works like this: * The thread, ticktack(), is a trivial routine that most of the time @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) sigint_fn = handler; break; + case SIGTERM: + sigterm_fn = handler; + break; + default: return signal(sig, handler); } @@ -1715,6 +1720,13 @@ int mingw_raise(int sig) sigint_fn(SIGINT); return 0; + case SIGTERM: + if (sigterm_fn == SIG_DFL) + exit(128 + SIGTERM); + else if (sigterm_fn != SIG_IGN) + sigterm_fn(SIGTERM); + return 0; + default: return raise(sig); } -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fetch doc: escape asterisk in --tags paragraph
Currently, the paragraph corresponding to the --tags option in git-fetch(1) looks like: -t, --tags This is a short-hand for giving refs/tags/:refs/tags/ refspec ^^^ this is in bold This happens because the corresponding text in fetch-options.txt is refs/tags/*:refs/tags/*; asciidoc renders the text between the two asterisks in bold. Escape the first asterisk, correcting the text. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Candidate for maint? Documentation/fetch-options.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 9cb6496..5f68149 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -61,7 +61,7 @@ endif::git-pull[] ifndef::git-pull[] -t:: --tags:: - This is a short-hand for giving refs/tags/*:refs/tags/* + This is a short-hand for giving refs/tags/\*:refs/tags/* refspec from the command line, to ask all tags to be fetched and stored locally. Because this acts as an explicit refspec, the default refspecs (configured with the -- 1.8.3.20.g7940bce.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 6/7/2013 12:12, schrieb Erik Faye-Lund: On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net wrote: On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote: The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() just calls exit(3). After a bit of web searching, it seems to me that this behaviour of raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls that. In other words, the implementation of raise() is at an even lower level than mingw/msys, and I would agree that it is a platform issue. Yeah, if it were mingw_raise responsible for this, I would suggest using the POSIX shell 128+sig instead. We could potentially check for SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if that would create headaches or confusion for other msys programs, though. I'd leave that up to the msysgit people to decide whether it is worth the trouble. ...and here's the code to do just that: diff --git a/compat/mingw.c b/compat/mingw.c index b295e2f..8b3c1b4 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1573,7 +1573,8 @@ static HANDLE timer_event; static HANDLE timer_thread; static int timer_interval; static int one_shot; -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL; +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL, +sigterm_fn = SIG_DFL; /* The timer works like this: * The thread, ticktack(), is a trivial routine that most of the time @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) sigint_fn = handler; break; + case SIGTERM: + sigterm_fn = handler; + break; + default: return signal(sig, handler); } @@ -1715,6 +1720,13 @@ int mingw_raise(int sig) sigint_fn(SIGINT); return 0; + case SIGTERM: + if (sigterm_fn == SIG_DFL) + exit(128 + SIGTERM); + else if (sigterm_fn != SIG_IGN) + sigterm_fn(SIGTERM); + return 0; + default: return raise(sig); } That's pointless and does not work. The handler would only be called when raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C from the command line, because that route ends up in MSVCRT, which does not know about this handler. That's not entirely true. On Windows, there's only *one* way to generate SIGTERM; signal(SIGTERM). Ctrl+C does not generate SIGTERM. We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C handler routine calls ExitProcess(): http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx So I believe this *does* entirely fix SIGTERM (as we currently know it) on Windows. SIGINT is still not entirely clean, but we can fix that on a case-by-case basis. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Follow perlcritic's recommendations - level 5 and 4
Le 07/06/2013 10:10, Matthieu Moy a écrit : It would be cool to have a make perlcritic target in the Makefile so that future developers can easily re-run it and avoid repeating the same mistakes. As much as possible, make perlcritic should produce no output at the end of your patch series (either the warnings should be fixed, or they should be disabled). The problem is that I took some policies into account for some parts of the code, but not for all of it. For instance, in commit [15/18], I put some numeric values in constants, but not all of them, as I think having arg[3] in the code does make sense. Ignoring this policy for future developement just to prevent the related warnings from appearing would prevent us to see useful warning messages from this policy. Therefore, there still are a dozen warning messages appearing in the current state... Anyway, should this be integrated in the current patch or added as an independant patch? -- Célestin Matte -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
Am 6/7/2013 14:00, schrieb Erik Faye-Lund: On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 6/7/2013 12:12, schrieb Erik Faye-Lund: On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net wrote: On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote: The particular deficiency is that when a signal is raise()d whose SIG_DFL action will cause process death (SIGTERM in this case), the implementation of raise() just calls exit(3). After a bit of web searching, it seems to me that this behaviour of raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls that. In other words, the implementation of raise() is at an even lower level than mingw/msys, and I would agree that it is a platform issue. Yeah, if it were mingw_raise responsible for this, I would suggest using the POSIX shell 128+sig instead. We could potentially check for SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if that would create headaches or confusion for other msys programs, though. I'd leave that up to the msysgit people to decide whether it is worth the trouble. ...and here's the code to do just that: diff --git a/compat/mingw.c b/compat/mingw.c index b295e2f..8b3c1b4 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1573,7 +1573,8 @@ static HANDLE timer_event; static HANDLE timer_thread; static int timer_interval; static int one_shot; -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL; +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL, +sigterm_fn = SIG_DFL; /* The timer works like this: * The thread, ticktack(), is a trivial routine that most of the time @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) sigint_fn = handler; break; + case SIGTERM: + sigterm_fn = handler; + break; + default: return signal(sig, handler); } @@ -1715,6 +1720,13 @@ int mingw_raise(int sig) sigint_fn(SIGINT); return 0; + case SIGTERM: + if (sigterm_fn == SIG_DFL) + exit(128 + SIGTERM); + else if (sigterm_fn != SIG_IGN) + sigterm_fn(SIGTERM); + return 0; + default: return raise(sig); } That's pointless and does not work. The handler would only be called when raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C from the command line, because that route ends up in MSVCRT, which does not know about this handler. That's not entirely true. On Windows, there's only *one* way to generate SIGTERM; signal(SIGTERM). Ctrl+C does not generate SIGTERM. We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C handler routine calls ExitProcess(): http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx But a call to signal(SIGTERM, my_handler) should divert Ctrl+C to my_handler. The unpatched version does, because MSVCRT now knows about my_handler and sets things up so that the event handler calls my_handler. But your patched version bypasses MSVCRT, and the default (whatever MSVCRT has set up) happens, and my_handler is not called. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
branch.name.pushremote not working with push.default simple or upstream
Hi, I tried to use the new Git feature to push by default to a different remote you normally pull but I had some problems. I asked in the #git IRC channel and been told it looks like a bug and to report it here. I have 2 remotes, origin and upstream. origin is my private fork (and I can push to it) while upstream is read-only for me. I have only one branch, 'master' (present in all the remotes), originally tracking origin/master. I changed branch.master.remote to upstream and set branch.master.pushremote to origin, but when I do I git push I get an error: $ git push --dry-run --verbose fatal: You are pushing to remote 'origin', which is not the upstream of your current branch 'master', without telling me what to push to update which remote branch. I'm using push.default 'simple' to stay forward compatible with Git 2.0. In the IRC channel they suggested to try with other push.default settings and I did. 'matching' and 'current' works, but 'simple' and 'upstream' fail with the error message above. Thank you. -- Leandro Lucarella Senior RD Developer sociomantic labs GmbH http://www.sociomantic.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 14:00, schrieb Erik Faye-Lund:
On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/7/2013 12:12, schrieb Erik Faye-Lund:
On Thu, Jun 6, 2013 at 7:40 PM, Jeff King p...@peff.net wrote:
On Thu, Jun 06, 2013 at 10:21:47AM -0700, Junio C Hamano wrote:
The particular deficiency is that when a signal is raise()d whose
SIG_DFL
action will cause process death (SIGTERM in this case), the
implementation of raise() just calls exit(3).
After a bit of web searching, it seems to me that this behaviour of
raise() is in msvcrt, and compat/mingw.c::mingw_raise() just calls
that. In other words, the implementation of raise() is at an even
lower level than mingw/msys, and I would agree that it is a platform
issue.
Yeah, if it were mingw_raise responsible for this, I would suggest using
the POSIX shell 128+sig instead. We could potentially check for
SIG_DFL[1] mingw_raise and intercept and exit there. I don't know if
that would create headaches or confusion for other msys programs,
though. I'd leave that up to the msysgit people to decide whether it is
worth the trouble.
...and here's the code to do just that:
diff --git a/compat/mingw.c b/compat/mingw.c
index b295e2f..8b3c1b4 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1573,7 +1573,8 @@ static HANDLE timer_event;
static HANDLE timer_thread;
static int timer_interval;
static int one_shot;
-static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL;
+static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL,
+sigterm_fn = SIG_DFL;
/* The timer works like this:
* The thread, ticktack(), is a trivial routine that most of the time
@@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig,
sig_handler_t handler)
sigint_fn = handler;
break;
+ case SIGTERM:
+ sigterm_fn = handler;
+ break;
+
default:
return signal(sig, handler);
}
@@ -1715,6 +1720,13 @@ int mingw_raise(int sig)
sigint_fn(SIGINT);
return 0;
+ case SIGTERM:
+ if (sigterm_fn == SIG_DFL)
+ exit(128 + SIGTERM);
+ else if (sigterm_fn != SIG_IGN)
+ sigterm_fn(SIGTERM);
+ return 0;
+
default:
return raise(sig);
}
That's pointless and does not work. The handler would only be called when
raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C
from the command line, because that route ends up in MSVCRT, which does
not know about this handler.
That's not entirely true. On Windows, there's only *one* way to
generate SIGTERM; signal(SIGTERM). Ctrl+C does not generate SIGTERM.
We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C
handler routine calls ExitProcess():
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx
But a call to signal(SIGTERM, my_handler) should divert Ctrl+C to
my_handler. The unpatched version does, because MSVCRT now knows about
my_handler and sets things up so that the event handler calls my_handler.
No, it does not:
---8---
#include signal.h
#include stdio.h
#include stdlib.h
void my_handler(int signum)
{
printf(signal: %d\n, signum);
exit(1);
}
int main()
{
signal(SIGTERM, my_handler);
while (1);
return 0;
}
---8---
This quietly kills the process on Windows with MSVCRT's
signal-implementation. In fact SIGTERM isn't raised on Linux either.
Ctrl+C raises SIGINT, not SIGTERM.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a library for monitoring a git repository for any changes?
On Thursday, June 06, 2013 at 23:16 EDT, Robert Martin rdmart...@gmail.com wrote: I want to work on a visualization program for git. I was hoping there was a library that would allow me to monitor a git repo for changes. Consider it like inotify, but for a git repository (in fact, I think it would probably have inotify under the hood). This hypothetical library would trigger an event any time the repository was modified, i.e. any time the graph that represents history was changed. Is there such a library? If not, is there a better way to monitor the repository so that I wouldn't need to write it myself? Would anyone else be interested if I wrote it myself? 'git ls-remote'? Either run periodically or, if the monitored git is local, triggered via inotify. If you have control over the git perhaps a post-receive hook would be useful too. -- Magnus Bäck ba...@google.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
Am 6/7/2013 14:46, schrieb Erik Faye-Lund: On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 6/7/2013 14:00, schrieb Erik Faye-Lund: On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 6/7/2013 12:12, schrieb Erik Faye-Lund: diff --git a/compat/mingw.c b/compat/mingw.c index b295e2f..8b3c1b4 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1573,7 +1573,8 @@ static HANDLE timer_event; static HANDLE timer_thread; static int timer_interval; static int one_shot; -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL; +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL, +sigterm_fn = SIG_DFL; /* The timer works like this: * The thread, ticktack(), is a trivial routine that most of the time @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) sigint_fn = handler; break; + case SIGTERM: + sigterm_fn = handler; + break; + default: return signal(sig, handler); } @@ -1715,6 +1720,13 @@ int mingw_raise(int sig) sigint_fn(SIGINT); return 0; + case SIGTERM: + if (sigterm_fn == SIG_DFL) + exit(128 + SIGTERM); + else if (sigterm_fn != SIG_IGN) + sigterm_fn(SIGTERM); + return 0; + default: return raise(sig); } That's pointless and does not work. The handler would only be called when raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C from the command line, because that route ends up in MSVCRT, which does not know about this handler. That's not entirely true. On Windows, there's only *one* way to generate SIGTERM; signal(SIGTERM). Ctrl+C does not generate SIGTERM. We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C handler routine calls ExitProcess(): http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx But a call to signal(SIGTERM, my_handler) should divert Ctrl+C to my_handler. The unpatched version does, because MSVCRT now knows about my_handler and sets things up so that the event handler calls my_handler. No, it does not: Ctrl+C raises SIGINT, not SIGTERM. action type=slap destination=forehead/ You are right. Your change would fix SIGTERM as it can be raised only via raise() on Windows nor can it be caught when a process is killed via mingw_kill(...,SIGTERM) by another process. But then the current handling of SIGINT in compat/mingw.c is broken. The handler is not propagated to MSVCRT, and after a SIGINT handler is installed, Ctrl+C still terminates the process. No? BTW, isn't mingw_signal() bogus in that it returns the SIGALRM handler even if a SIGINT handler is installed? -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
[+CC: jc, jk]
Leandro Lucarella wrote:
I changed branch.master.remote to upstream and set
branch.master.pushremote to origin, but when I do I git push I get an
error:
$ git push --dry-run --verbose
fatal: You are pushing to remote 'origin', which is not the upstream of
your current branch 'master', without telling me what to push
to update which remote branch.
Yes, this is a defect: both remote.pushdefault and
branch.name.pushremote suffer from it.
Let me explain what's happening. The error is triggered off in
setup_push_upstream() in builtin/push.c (which both simple and
upstream use). It's exactly the same error that will be reported if
you do the following without a branch.master.pushremote or
remote.pushdefault configured:
$ git push origin --dry-run --verbose
fatal: You are pushing to remote 'origin', which is not the upstream of
your current branch 'master', without telling me what to push
to update which remote branch.
You should therefore be able to infer that remote.pushdefault/
branch.name.pushremote is simply saving you from remembering/ typing
out that origin on the command-line. The error precisely describes
the problem. To understand what this upstream the error is talking
about, see:
$ git rev-parse --symbolic-full-name @{u}
refs/remotes/upstream/master
So, if you are pushing to upstream, the push knows what to do: push to
the refspec branch:branch@{u} (see builtin/push.c:148). If you're
pushing to origin, it has no idea _what_ to push, and hence errors
out. By design, upstream/ simple assume that you push to the same
place that you pull from: the description clearly says that it is
intended to make the push and pull symmetric.
Finally, the reason remote.pushdefault/ branch.name.pushremote works
in the other modes is simple: in matching and current, the push
refspec is not dependent on the current branch's upstream. In
matching, the refspec it is the constant :, and in current, it is
the constant HEAD (will subtly change with rr/push-head).
I think the correct fix is to change the semantics of upstream/simple
to dictate a refspec independent of remote. So, if:
1. branch.master.merge is configured to refs/heads/rr/master
2. branch.master.remote is configured to origin
3. remote.pushdefault is configured to ram
4. push.default is configured to upstream
Then, the a push should push the refspec master:rr/master to the
remote ram. Let's see what the others have to say before proceeding.
Thank you for reporting this problem. It is indeed very serious,
especially since simple is going to be default in Git 2.0.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t0005: skip signal death exit code test on Windows
On Fri, Jun 7, 2013 at 3:07 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 6/7/2013 14:46, schrieb Erik Faye-Lund: On Fri, Jun 7, 2013 at 2:19 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 6/7/2013 14:00, schrieb Erik Faye-Lund: On Fri, Jun 7, 2013 at 12:24 PM, Johannes Sixt j.s...@viscovery.net wrote: Am 6/7/2013 12:12, schrieb Erik Faye-Lund: diff --git a/compat/mingw.c b/compat/mingw.c index b295e2f..8b3c1b4 100644 --- a/compat/mingw.c +++ b/compat/mingw.c @@ -1573,7 +1573,8 @@ static HANDLE timer_event; static HANDLE timer_thread; static int timer_interval; static int one_shot; -static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL; +static sig_handler_t timer_fn = SIG_DFL, sigint_fn = SIG_DFL, +sigterm_fn = SIG_DFL; /* The timer works like this: * The thread, ticktack(), is a trivial routine that most of the time @@ -1688,6 +1689,10 @@ sig_handler_t mingw_signal(int sig, sig_handler_t handler) sigint_fn = handler; break; + case SIGTERM: + sigterm_fn = handler; + break; + default: return signal(sig, handler); } @@ -1715,6 +1720,13 @@ int mingw_raise(int sig) sigint_fn(SIGINT); return 0; + case SIGTERM: + if (sigterm_fn == SIG_DFL) + exit(128 + SIGTERM); + else if (sigterm_fn != SIG_IGN) + sigterm_fn(SIGTERM); + return 0; + default: return raise(sig); } That's pointless and does not work. The handler would only be called when raise() is called, but not when a SIGTERM is received, e.g., via Ctrl-C from the command line, because that route ends up in MSVCRT, which does not know about this handler. That's not entirely true. On Windows, there's only *one* way to generate SIGTERM; signal(SIGTERM). Ctrl+C does not generate SIGTERM. We generate SIGINT on Ctrl+C in mingw_fgetc, but the default Control+C handler routine calls ExitProcess(): http://msdn.microsoft.com/en-us/library/windows/desktop/ms683242(v=vs.85).aspx But a call to signal(SIGTERM, my_handler) should divert Ctrl+C to my_handler. The unpatched version does, because MSVCRT now knows about my_handler and sets things up so that the event handler calls my_handler. No, it does not: Ctrl+C raises SIGINT, not SIGTERM. action type=slap destination=forehead/ You are right. Your change would fix SIGTERM as it can be raised only via raise() on Windows nor can it be caught when a process is killed via mingw_kill(...,SIGTERM) by another process. But then the current handling of SIGINT in compat/mingw.c is broken. The handler is not propagated to MSVCRT, and after a SIGINT handler is installed, Ctrl+C still terminates the process. No? Yeah, probably. I wasn't aware that it handled SIGINT, but yeah it does. So this was indeed a regression. BTW, isn't mingw_signal() bogus in that it returns the SIGALRM handler even if a SIGINT handler is installed? Yep, that's a bug. Thanks for noticing. I've pushed out a branch here that tries to address these issues, but I haven't had time to test them. I'll post the series when I have. In the mean time: https://github.com/kusma/git/tree/win32-signal-raise -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
David Lang wrote: Well, Felipe is saying that Perl is dieing and we should re-write everything that exists in Perl to Ruby. I don't agree with that opinion. More generally, I think the entire discussion on what _should_ or _should not_ be done is rubbish. What _will_ and _will not_ happen depends on the patches contributors send. If a contributor sends a patch rewriting git-svn in ruby, then we have a discussion: is anyone bored enough to pick up the task in the first place? TIOBE index graph is press coverage as far as I'm concerned. Well, that's your definition of press coverage then. TIOBE index is generated from scraping the web to figure out which languages are living, based on discussions between programmers (and yes, press articles). I do not have conclusive or undeniable proof that perl is dying, but the trends are indicative of a decline. I think Felipe is using the argument that perl is declining to answer the question why didn't you write git-related in perl instead?; that's it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch doc: escape asterisk in --tags paragraph
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, the paragraph corresponding to the --tags option in
git-fetch(1) looks like:
-t, --tags
This is a short-hand for giving refs/tags/:refs/tags/ refspec
^^^
this is in bold
This happens because the corresponding text in fetch-options.txt is
refs/tags/*:refs/tags/*; asciidoc renders the text between the two
asterisks in bold. Escape the first asterisk, correcting the text.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Candidate for maint?
The issue certainly is real and needs a fix for maint. Your
solution I am not sure about.
$ git grep '\\\*' -- Documentation/\*.txt
shows only two meaningful hits (git-rm.txt and git-svn.txt);
everybody else uses
$ git grep '{asterisk}' -- Documentation/\*.txt
and the one you spotted in fetch-options.txt is very similar to the
one appears in git-pull.txt, I think.
Documentation/fetch-options.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 9cb6496..5f68149 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -61,7 +61,7 @@ endif::git-pull[]
ifndef::git-pull[]
-t::
--tags::
- This is a short-hand for giving refs/tags/*:refs/tags/*
+ This is a short-hand for giving refs/tags/\*:refs/tags/*
refspec from the command line, to ask all tags to be fetched
and stored locally. Because this acts as an explicit
refspec, the default refspecs (configured with the
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch doc: escape asterisk in --tags paragraph
Junio C Hamano gits...@pobox.com writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, the paragraph corresponding to the --tags option in
git-fetch(1) looks like:
-t, --tags
This is a short-hand for giving refs/tags/:refs/tags/ refspec
^^^
this is in bold
This happens because the corresponding text in fetch-options.txt is
refs/tags/*:refs/tags/*; asciidoc renders the text between the two
asterisks in bold. Escape the first asterisk, correcting the text.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Candidate for maint?
The issue certainly is real and needs a fix for maint. Your
solution I am not sure about.
$ git grep '\\\*' -- Documentation/\*.txt
shows only two meaningful hits (git-rm.txt and git-svn.txt);
everybody else uses
$ git grep '{asterisk}' -- Documentation/\*.txt
and the one you spotted in fetch-options.txt is very similar to the
one appears in git-pull.txt, I think.
How about this?
-- 8 --
Subject: fetch-options.txt: prevent wildcard refspec from getting misformatted
When explaining the --tags option as an equivalent to giving an
explicit refs/tags/*:refs/tags/* refspec, the two asterisks were
misinterpreted by AsciiDoc as a request to typeset the string
segment between them in bold.
We could fix it in two ways. We can replace them with {asterisk}s
while keeping the string as body text, or we can mark it as a
literal string by using the backquotes around it.
Let's do the latter, as it is teaching the user an exactly as
typed alternative.
Noticed-by: Ramkumar Ramachandra artag...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/fetch-options.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 6e98bdf..c87bf39 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -57,7 +57,7 @@ endif::git-pull[]
ifndef::git-pull[]
-t::
--tags::
- This is a short-hand for giving refs/tags/*:refs/tags/*
+ This is a short-hand for giving `refs/tags/*:refs/tags/*`
refspec from the command line, to ask all tags to be fetched
and stored locally. Because this acts as an explicit
refspec, the default refspecs (configured with the
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fetch doc: escape asterisk in --tags paragraph
Junio C Hamano wrote: How about this? Looks good, thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Junio C Hamano wrote: So at least for now, the conclusion is to take approach #1, i.e. somebody who finds related a good addition rewrites it in Perl to promote it out of contrib/ once the design issues settle (of course it is still a possibility that no such volunteer appears). We'll think about it if and when we get major ruby patches, and see perl patches declining. One git-related.rb doesn't say anything. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] completion: add common options for rev-parse
Ramkumar Ramachandra wrote: Add support for completing 'git rev-parse'. List only the options that are likely to be used on the command-line, as opposed to scripts. Can we get this patch? I use git rev-list quite a lot, and want completion. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
Ramkumar Ramachandra artag...@gmail.com writes:
[+CC: jc, jk]
Leandro Lucarella wrote:
I changed branch.master.remote to upstream and set
branch.master.pushremote to origin, but when I do I git push I get an
error:
$ git push --dry-run --verbose
fatal: You are pushing to remote 'origin', which is not the upstream of
your current branch 'master', without telling me what to push
to update which remote branch.
Yes, this is a defect: both remote.pushdefault and
branch.name.pushremote suffer from it.
The upstream and simple modes have been defined to push to
upstream repository in central-shared-repository workflow.
At this point in Leandro's example, I think the configuration is:
[branch master]
remote = upstream
merge = refs/heads/master
pushremote = origin
and master@{u} == upstream's master, not origin's.
This shows the triangular support in 1.8.3 is only half-finished;
the other half was discussed a few weeks ago ($gmane/224604), but I
do not recall what the current status of the topic is. I personally
think 'single' the root level of the thread hints is an overkill
mechanism, so here is a suggestion to show one possible way forward.
Until the branch.$name.push mechanism is introduced to specify which
destination branch is updated by the push, and/or branch.$name.push
is not specified after such a mechanism is introduced, I think the
natural extension of the current end-user configuration would be to
redefine upstream mode to push to update the branch with the same
name (in the above example, 'master' of 'origin' is updated), when
the repository that is pushed to, which is different from the
repository that is fetched from is specified via remote.pushdefault
or branch.$name.pushremote mechanisms.
This incidentally covers simple mode, because pushing to update
the branch with the same name is the only behaviour accepted by the
mode anyway.
When branch.$name.push mechanism is introduced and the user uses it,
then upstream, simple, or any other setting for that matter
would be ignored. With
[branch master]
remote = upstream
merge = refs/heads/master
pushremote = origin
push = refs/heads/master
it is clear that git push while on 'master' should push to origin
to update its master branch.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
Forgot to cc; sorry about that. Junio C Hamano gits...@pobox.com writes: SZEDER Gábor sze...@ira.uka.de writes: On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote: * rr/complete-difftool (2013-06-03) 2 commits (merged to 'next' on 2013-06-04 at 01c7611) + completion: clarify ls-tree, archive, show completion + completion: difftool takes both revs and files Update command line completion (in contrib/) to use a better named completion helper function for commands that take revisions and paths. Will merge to 'master'. This should not be merged to master as is; the one at the top because of the reasons given in $gmane/226272, the one at the bottom because of the misleading commit message (__git_complete_file() always completed refs first as part of the ref:file notation, so it worked just fine except for the ref1...ref2 notation; the real reason for calling __git_complete_revlist_file() for difftool is to make clear that difftool takes ref1...ref2:file, too). Oops. It is too late to amend the log messages now, but at least a follow-up patch can fix the breakage by adding __git_complete_file() back. Would you mind doing that? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git diff bug?
On Thu, Jun 6, 2013 at 6:17 PM, Junio C Hamano gits...@pobox.com wrote: Célestin Matte celestin.ma...@ensimag.fr writes: But for a two-endpoint diff Porcelain (not the plumbing diff-files, diff-index and diff-tree), I do not think it is particularly a bad idea to add such a typo-detection feature. I was wondering if this feature is going to be added and if I could try implementing it. -- 010 001 111 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
On Fri, Jun 07, 2013 at 08:47:59AM -0700, Junio C Hamano wrote: When branch.$name.push mechanism is introduced and the user uses it, then upstream, simple, or any other setting for that matter would be ignored. With [branch master] remote = upstream merge = refs/heads/master pushremote = origin push = refs/heads/master it is clear that git push while on 'master' should push to origin to update its master branch. Thanks for the detailed explanations, I think this would cover my use case. Just for clarification, here are some more details on this use case, which I think is becoming very popular among github users. We have a blessed repository (upstream in my case) and only a few people is able to push to it (let's call them maintainers). Every developer, including the ones with push access, have to go through peer reviewing and are not allowed to push their own commits to upstream. For peer reviewing, each have it's own public fork, that other people can review and merge/push if is good. In this scheme, you always pull from the blessed repository and only push to your personal fork, with the exceptions of the maintainers that need to push from time to time other people pull requests. My ideal would be to be able to just do 'git pull' to get the new stuff and 'git push' to push to my fork. Since pushing to the blessed repository is more critical, is perfect that I need to explicitly push to it with 'git push upstream master'. Thank you. -- Leandro Lucarella Senior RD Developer sociomantic labs GmbH http://www.sociomantic.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy matthieu@grenoble-inp.fr writes: * Ask the user to build external programs with make GIT_ROOT=where/git/lives/ * or, ask users to checkout the external program as a subdirectory of git.git to build it (for example, clang's build installation ask you to put clang as a subdirectory of LLVM's tree). But my main point is that I think it would be easier to phase out contrib/ if there were a good alternate way of providing visibility to satellite projects. [...] Perhaps ranking the tools based on the results of the Git user surveys would help bring the most popular to the top of each category. I think this is the most important point. A good example would be git-multimail: for now, the shell version in contrib/ is somehow considered as the official hook to send emails, just because it is in contrib, while git-multimail is clearly superior (unless you don't have a python interpreter on your server). I was envisioning to sift what are in contrib/ into these four categories: (1) Ones that deserve to be Git subcommands; (2) Ones that are useful only in the context of using Git (e.g. hooks, completion scripts, credential and remote helpers); (3) Ones that are no longer useful; (4) Ones that primarily _use_ Git, not the other way around (i.e. opposite of category (2) which help use of Git). The first category will live next to git-am.sh (i.e. in the longer term when we restructure the source tree into src/, lib/, etc., candidates for new scripted subcommands move with the scripted Porcelains). The second category will be in a separate hierarchy (perhaps addons/, hooks/, ..., but I am fine if we decide to keep them in contrib/addons, contrib/hooks, etc.). The last two categories will be removed; people are welcome to decide which category between (3) and (4) each piece belongs to, and pick up to start a standalone third-party project. The multimail tool can be in the second category. It helps use of Git more than it is helped by using Git. I'm not opposed to Junio's proposal to restrict contrib/ (although a bit reluctant), but I think this should be done with care, at least to give potential users a way to chose which tool to use (really, nobody want to go use https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools to pick the right tool. It's a great list, but not a guide). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] Rebase topology test
Martin von Zweigbergk martinv...@gmail.com writes: Changes since v5: * Improved test_linear_range * Changed TODOs to be about consistency, not --topo-order Thanks, looked sensible. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
Junio C Hamano wrote:
This shows the triangular support in 1.8.3 is only half-finished;
the other half was discussed a few weeks ago ($gmane/224604)
I intentionally omitted that detail, because it is not directly
related to this bug. We have to fix the existing simple and upstream,
whether or not we introduce branch.name.push. I've personally
stopped working on branch.name.push, and am focusing on getting @{p}
first (you've already seen a dirty wip). The transport code
underlying the push is dirty enough, and I'd first like to understand
it before bolting on more features.
I think the
natural extension of the current end-user configuration would be to
redefine upstream mode to push to update the branch with the same
name
Right, so does this work?
diff --git a/builtin/push.c b/builtin/push.c
index 2d84d10..b253a64 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -137,11 +137,6 @@ static void setup_push_upstream(struct remote
if (branch-merge_nr != 1)
die(_(The current branch %s has multiple upstream branches,
refusing to push.), branch-name);
- if (strcmp(branch-remote_name, remote-name))
- die(_(You are pushing to remote '%s', which is not the
upstream of\n
- your current branch '%s', without telling me what to
push\n
- to update which remote branch.),
- remote-name, branch-name);
if (simple strcmp(branch-refname, branch-merge[0]-src))
die_push_simple(branch, remote);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
Leandro Lucarella wrote: Thanks for the detailed explanations, I think this would cover my use case. Just for clarification, here are some more details on this use case, which I think is becoming very popular among github users. We have a blessed repository (upstream in my case) and only a few people is able to push to it (let's call them maintainers). Every developer, including the ones with push access, have to go through peer reviewing and are not allowed to push their own commits to upstream. For peer reviewing, each have it's own public fork, that other people can review and merge/push if is good. Yes, and I wrote it precisely to address this itch. git/git is origin, and artagnon/git is ram. I just set remote.pushdefault to ram and continue working as usual. I apologize for not having thought hard enough about other push.default modes: I personally use current, and like it very much. As an added bonus, even new branches created with git checkout -b hot-branch will get push to go to the right place; no need to set upstream before pushing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] Turn double-negated expressions into simple expressions
Le 07/06/2013 06:12, Eric Sunshine a écrit :
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 68fd129..a6c7de2 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -136,16 +136,16 @@ while (STDIN) {
if (defined($cmd[0])) {
# Line not blank
if ($cmd[0] eq capabilities) {
- die(Too many arguments for capabilities\n) unless
(!defined($cmd[1]));
+ die(Too many arguments for capabilities\n) if
(defined($cmd[1]));
mw_capabilities();
} elsif ($cmd[0] eq list) {
- die(Too many arguments for list\n) unless
(!defined($cmd[2]));
+ die(Too many arguments for list\n) if
(defined($cmd[2]));
mw_list($cmd[1]);
} elsif ($cmd[0] eq import) {
- die(Invalid arguments for import\n) unless
($cmd[1] ne !defined($cmd[2]));
+ die(Invalid arguments for import\n) if ($cmd[1] eq
|| defined($cmd[2]));
mw_import($cmd[1]);
} elsif ($cmd[0] eq option) {
- die(Too many arguments for option\n) unless
($cmd[1] ne $cmd[2] ne !defined($cmd[3]));
+ die(Too many arguments for option\n) if ($cmd[1]
eq || $cmd[2] eq || defined($cmd[3]));
Not new in this patch, but isn't this diagnostic misleading? It will
(falsely) claim too many arguments if $cmd[1] or $cmd[2] is an empty
string. Perhaps it should be reworded like the 'import' diagnostic and
say Invalid arguments for option.
We could even be more precise and separate the cases, i.e., die(Too
many arguments) when too many arguments are defined and die(Invalid
arguments) when there are empty strings.
Not sure if I should integrate it in this patch, though.
--
Célestin Matte
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is there a fast web-interface to git for huge repos?
On 6 June 2013 23:33, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote: I'm interested in running a web interface to this and other similar git repositories (FreeBSD and NetBSD git repositories are even much, much bigger). Software-wise, is there no way to make cold access for git-log and git-blame to be orders of magnitude less than ~5s, and warm access less than ~0.5s? The obvious way would be to cache the results. You can even put an That would do nothing to prevent slowness of the cold requests, which already run for 5s when completely cold. In fact, unless done right, it would actually slow things down, as lines would not necessarily show up as they're ready. update cache hook the git repositories to make the cache always be up to date. That's entirely inefficient. It'll probably take hours or days to pre-cache all the html pages with a naive wget and the list of all the files. Not a solution at all. (0.5s x 35k files = 5 hours for log/blame, plus another 5h of cpu time for blame/log) There's some dynamic web frontends like cgit and gitweb out there but there's also static ones like git-arr ( http://blitiri.com.ar/p/git-arr/ ) that might be more of an option to you. The concept for git-arr looks interesting, but it has neither blame nor log, so, it's kinda pointless, because the whole thing that's slow is exactly blame and log. There has to be some way to improve these matters. Noone wants to wait 5 seconds until a page is generated, we're not running enterprise software here, latency is important! C. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
On Fri, Jun 07, 2013 at 10:27:58PM +0530, Ramkumar Ramachandra wrote: Leandro Lucarella wrote: Thanks for the detailed explanations, I think this would cover my use case. Just for clarification, here are some more details on this use case, which I think is becoming very popular among github users. We have a blessed repository (upstream in my case) and only a few people is able to push to it (let's call them maintainers). Every developer, including the ones with push access, have to go through peer reviewing and are not allowed to push their own commits to upstream. For peer reviewing, each have it's own public fork, that other people can review and merge/push if is good. Yes, and I wrote it precisely to address this itch. git/git is origin, and artagnon/git is ram. I just set remote.pushdefault to ram and continue working as usual. I apologize for not having thought hard enough about other push.default modes: I personally use current, and like it very much. As an added bonus, even new branches created with git checkout -b hot-branch will get push to go to the right place; no need to set upstream before pushing. I might try to just switch to current, I feel more comfortable with simple because I feel is safer to explicitly set the upstream branch, but is true that most of the time is not necessary. -- Leandro Lucarella Senior RD Developer sociomantic labs GmbH http://www.sociomantic.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] completion: clarify ls-tree, archive, show completion
SZEDER Gábor wrote: Well, people out there might have completion scriplets for their aliases or custom git commands which use __git_complete_file(). Removing this function would break those scripts. What is the advantage of using __git_complete_file() over __git_complete_revlist_file()? Isn't it just a misleading alias? Arguably the name of __git_complete_file() could describe better what the function does, or what it did, i.e. it used to provide completion for the master:DocTAB notation. But that's only the name. Since both git ls-tree and git archive understand this notation, calling the helper for master:DocTAB in their completion functions is not misleading at all. But __git_complete_revlist_file() provides all this and more, no? Now, __git_complete_revlist_file() provides completion both for this master:DocTAB notation and for revision ranges, i.e. for master..nTAB and master...nTAB. However, since neither git ls-tree nor git archive accept revision ranges, calling __git_complete_revlist_file() in their completion function would be misleading. Yeah, they accept tree-ish'es. Isn't __git_complete_file() still a horrible name? $ git ls-tree HEAD:Documentation What file? There's already a __git_complete_index_file(), which is properly named and used by the ls-files family. If anything, we should write a new __git_complete_treeish() function that does what __git_complete_revlist_file() does, except that it doesn't complete revision ranges, right? Frankly, I don't know if it's worth the additional trouble: we do spurious completions all over the place, and we haven't clamped down on any of that. $ git log HEAD:DocTAB Note how log doesn't even error out. git show is special, as it understands both the master:DocTAB notation and revision ranges, and even the combination of the two, so calling __git_complete_revlist_file() there would indeed be better. It just accepts any revspec with pathspec filtering, like many many other commands. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
SZEDER Gábor wrote: the one at the top because of the reasons given in $gmane/226272 Sorry about the delay: I went to sleep for a couple of days :P the one at the bottom because of the misleading commit message (__git_complete_file() always completed refs first as part of the ref:file notation, so it worked just fine except for the ref1...ref2 notation; the real reason for calling __git_complete_revlist_file() for difftool is to make clear that difftool takes ref1...ref2:file, too). How am I (or anyone else) supposed to know the intended meaning __git_complete_file()? The implementation is just an alias to __git_complete_revlist_file(), so I looked at the name and guessed that it was supposed to complete files; now you tell me that it was intended to complete any revspec except revision ranges (what does that have to do with file again?). I suppose digging through the history would've told me, but I really didn't bother for such a trivial non-functional change. If you ask me, you should clamp down on spurious completions everywhere uniformly, if that is what you want (I personally have no interest in the topic). I see no reason to keep a badly named function around. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
Leandro Lucarella wrote: I might try to just switch to current, I feel more comfortable with simple because I feel is safer to explicitly set the upstream branch, but is true that most of the time is not necessary. Be more experimental! Use the lesser-known features, and tell us about breakages: that's how you can help git improve :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Follow perlcritic's recommendations - level 5 and 4
Célestin Matte celestin.ma...@ensimag.fr writes: The problem is that I took some policies into account for some parts of the code, but not for all of it. For instance, in commit [15/18], I put some numeric values in constants, but not all of them, as I think having arg[3] in the code does make sense. Ignoring this policy for future developement just to prevent the related warnings from appearing would prevent us to see useful warning messages from this policy. OK. Perhaps a make sloppy-perlcritic with zero output and a make pedantic-perlcritic with more policies can make sense. Or just make perlcritic, and accept that there are warnings. Anyway, should this be integrated in the current patch or added as an independant patch? That could be a new patch, preferably the first of the series. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is there a fast web-interface to git for huge repos?
On Fri, Jun 07, 2013 at 10:05:37AM -0700, Constantine A. Murenin wrote: On 6 June 2013 23:33, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote: I'm interested in running a web interface to this and other similar git repositories (FreeBSD and NetBSD git repositories are even much, much bigger). Software-wise, is there no way to make cold access for git-log and git-blame to be orders of magnitude less than ~5s, and warm access less than ~0.5s? The obvious way would be to cache the results. You can even put an That would do nothing to prevent slowness of the cold requests, which already run for 5s when completely cold. In fact, unless done right, it would actually slow things down, as lines would not necessarily show up as they're ready. You need to cache this _before_ the web-request. Don't let the web-request trigger a cache-update but a git push to the repository. update cache hook the git repositories to make the cache always be up to date. That's entirely inefficient. It'll probably take hours or days to pre-cache all the html pages with a naive wget and the list of all the files. Not a solution at all. (0.5s x 35k files = 5 hours for log/blame, plus another 5h of cpu time for blame/log) That's a one-time penalty. Why would that be a problem? And why is wget even mentioned? Did we misunderstood eachother? There's some dynamic web frontends like cgit and gitweb out there but there's also static ones like git-arr ( http://blitiri.com.ar/p/git-arr/ ) that might be more of an option to you. The concept for git-arr looks interesting, but it has neither blame nor log, so, it's kinda pointless, because the whole thing that's slow is exactly blame and log. There has to be some way to improve these matters. Noone wants to wait 5 seconds until a page is generated, we're not running enterprise software here, latency is important! C. Git's internal structures make just blame pretty expensive. There's nothing you really can do for it algoritm wise (as far as I know, if there was, people would already improved it). The solution here is to have a hot repository to speed up things. There's of course little things you can do. I imagine that using git repack in a sane way probably could speed things up, as well as git gc. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy wrote: Reading Git for Windows's FAQ ( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ), it seems rather clear that the TODO-list is already long to have a correct Perl support (I'm quite admirative of the work done already). The POSIX guys shouldn't move faster than the Windows guys can follow. Ha! So, it's subversion and perlxs. I was wondering what was so non-trivial about shipping a perl interpreter with Windows when dscho mentioned it. Hopefully, I've done a little bit to improve the situation by pushing svnrdump into core (I don't know if it has any users). On the git side, git-remote-testsvn is still a toy (which is a product of many months of work by db + 2x SoCs) compared to git-svn.perl. Yeah, supporting subversion is extraordinarily painful. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy wrote: I think it should be the Git for Windows community, and my feeling is that the community developing Git for POSIX systems is far more active than the one making it work for Windows (although we may now have more windows users than unix users). If I can be excused for being frank, and saying something potentially blasphemous: I think he way forward on Windows is an implementation like libgit2 or git# with some sort of gui/ide integration. I never understood why users on Windows want to use something as POSIX'y as git.git. Wouldn't they prefer some visual-studio integration thing? *scratches head* -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy matthieu@grenoble-inp.fr writes: The POSIX guys shouldn't move faster than the Windows guys can follow. That is a very good summary. It does not mean everybody must always crawl at the same pace as the slowest people. But it is one of the important things we should consider, when we have choices to make (e.g. do we write this in Python, do we write it using this Perl module we haven't depended on, etc.), to pick the one that does not make others work harder than necessary---it affects the trade-offs. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Ramkumar Ramachandra artag...@gmail.com writes: I think he way forward on Windows is an implementation like libgit2 or git# with some sort of gui/ide integration. I never understood why users on Windows want to use something as POSIX'y as git.git. Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. Wouldn't they prefer some visual-studio integration thing? *scratches head* Visual Studio now has official Git support from MS (based on libgit2 if I understood correctly). That's cool, but not a reason to kill msysgit IMHO ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
Ramkumar Ramachandra artag...@gmail.com writes:
SZEDER Gábor wrote:
the one at the top because
of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P
the one at the bottom because
of the misleading commit message (__git_complete_file() always
completed refs first as part of the ref:file notation, so it worked
just fine except for the ref1...ref2 notation; the real reason for
calling __git_complete_revlist_file() for difftool is to make clear
that difftool takes ref1...ref2:file, too).
How am I (or anyone else) supposed to know the intended meaning
__git_complete_file()?
git log -Gcomplete_file -p contrib/completion found this one:
commit 1d66ec587e7d903afdf12a81718772a9eadc15a1
Author: SZEDER Gábor sze...@ira.uka.de
Date: Thu Mar 10 19:12:29 2011 +0100
bash: complete 'git diff ...brancTAB'
While doing a final sanity check before merging a topic Bsomething, it
is a good idea to review what damage Bsomething branch would make, by
running:
$ git diff ...Bsomething
Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'. This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'tree:path' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'. Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support 'tree:path'.
To support both '...ref' and 'tree:path' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file(). The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.
This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:DocTAB' and 'git log master:DocTAB' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: SZEDER Gábor sze...@ira.uka.de
Signed-off-by: Junio C Hamano gits...@pobox.com
Now I do not recall suggesting it, and you (and I today after 2
years) may disagree with the rationale, but at least we can read
what was the intended meaning, I think.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] completion: clarify ls-tree, archive, show completion
On Fri, Jun 07, 2013 at 10:51:53PM +0530, Ramkumar Ramachandra wrote: SZEDER Gábor wrote: Well, people out there might have completion scriplets for their aliases or custom git commands which use __git_complete_file(). Removing this function would break those scripts. What is the advantage of using __git_complete_file() over __git_complete_revlist_file()? That it doesn't imply that the command takes refs in the form of ref1..ref2. Isn't it just a misleading alias? No. It's an implementation detail that __git_complete_file() became an alias to __git_complete_revlist_file() to avoid unnecessary code duplication. And it was a concious decision to keep __git_complete_file() (and __git_complete_revlist()) around in order not to break completion scriplets for users' alieses and custom git commands which might call it. Arguably the name of __git_complete_file() could describe better what the function does, or what it did, i.e. it used to provide completion for the master:DocTAB notation. But that's only the name. Since both git ls-tree and git archive understand this notation, calling the helper for master:DocTAB in their completion functions is not misleading at all. But __git_complete_revlist_file() provides all this and more, no? Indeed, and this more is exactly why it is misleading to call __git_complete_revlist_file() directly for git ls-tree and git archive. Now, __git_complete_revlist_file() provides completion both for this master:DocTAB notation and for revision ranges, i.e. for master..nTAB and master...nTAB. However, since neither git ls-tree nor git archive accept revision ranges, calling __git_complete_revlist_file() in their completion function would be misleading. Yeah, they accept tree-ish'es. Isn't __git_complete_file() still a horrible name? We can't go back in time to correct it, unfortunately. If anything, we should write a new __git_complete_treeish() function that does what __git_complete_revlist_file() does, except that it doesn't complete revision ranges, right? Frankly, I don't know if it's worth the additional trouble I agree that it isn't worth it, and that is exactly why __git_complete_revlist() and __git_complete_file() were unified in __git_complete_revlist_file(). $ git log HEAD:DocTAB Note how log doesn't even error out. But note how git log master..HEAD:Documentation/ errors out. git show is special, as it understands both the master:DocTAB notation and revision ranges, and even the combination of the two, so calling __git_complete_revlist_file() there would indeed be better. It just accepts any revspec with pathspec filtering, like many many other commands. Which many many other commands do accept ref1..ref2:file? Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git stash while pending merge should not be allowed
Scott McPeak smcp...@coverity.com writes: I suggest that this problem could easily have been avoided if git stash refused to run with a pending merge (present MERGE_HEAD file), since this is crucial repository state that it does not save. This seems similar to what git cherry-pick does. Sounds senslbe. What do we want to see happen in other states, in which Git gives control back to the user asking for help before moving forward (e.g. am, rebase, cherry-pick, revert)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Matthieu Moy wrote: Visual Studio now has official Git support from MS (based on libgit2 if I understood correctly). That's cool, but not a reason to kill msysgit IMHO ;-). Oh, I'm not interested in killing anything. If people want msysgit, they will work on it: I'm nobody to say otherwise. I was just curious to know why msysgit is suffering from a lack of attention: fewer users? Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. I see. But isn't it possible to implement a CLI in libgit2 too, no? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Jonathan Nieder wrote: Ramkumar Ramachandra wrote: I think he way forward on Windows is Why is there only one way forward? Why do you get to pick it, given that you've said you're not interested in working on it? [...] I never understood why users on Windows want to use something as POSIX'y as git.git. Plenty of users on Windows use a command line. I have even been such a user from time to time. I'm quite grateful for Dscho et al's work on making that less painful. Jonathan I agree completely. It's rare that I use Windows now, but a few years ago I installed Cygwin on any machine that I would use in any serious capacity. I haven't needed to do this since I started to use Git; the Windows installer ships all of the POSIX utilities that I need (with the possible exception of 'tree', and the caveat that scp can't handle files = 2GB). I'm very appreciative of the work that's gone in to Git for Windows, and from my perspective it's a pleasant coincidence that it includes a POSIX shell and associated tools. MMR... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
On Fri, Jun 07, 2013 at 11:00:14PM +0530, Ramkumar Ramachandra wrote: SZEDER Gábor wrote: the one at the top because of the reasons given in $gmane/226272 Sorry about the delay: I went to sleep for a couple of days :P the one at the bottom because of the misleading commit message (__git_complete_file() always completed refs first as part of the ref:file notation, so it worked just fine except for the ref1...ref2 notation; the real reason for calling __git_complete_revlist_file() for difftool is to make clear that difftool takes ref1...ref2:file, too). How am I (or anyone else) supposed to know the intended meaning __git_complete_file()? The implementation is just an alias to __git_complete_revlist_file(), so I looked at the name and guessed that it was supposed to complete files; now you tell me that it was intended to complete any revspec except revision ranges (what does that have to do with file again?). I suppose digging through the history would've told me, but I really didn't bother for such a trivial non-functional change. Yeah, I suppose it's always wise to do a bit of history digging before you go on to remove a function you don't know what it is doing, even though a simple git log -Sfuncname perhaps doesn't even qualifies for digging ;) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Ramkumar Ramachandra artag...@gmail.com writes: Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. I see. But isn't it possible to implement a CLI in libgit2 too, no? Yes (there have actually been several attempts at this like https://github.com/Romain-Geissler/git2 and https://github.com/vfr-nl/git2/), but there are a *lot* of stuff that are in git.git and not in libgit2. I'd love to see Git re-implemented on top of libgit2, but that's not going to happen tomorrow :-\. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
Junio C Hamano wrote: git log -Gcomplete_file -p contrib/completion found this one: Now I do not recall suggesting it, and you (and I today after 2 years) may disagree with the rationale, but at least we can read what was the intended meaning, I think. Having spent so much time documenting pickaxe, I should atleast learn to use it more often :\ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: is there a fast web-interface to git for huge repos?
On 7 June 2013 10:57, Fredrik Gustafsson iv...@iveqy.com wrote: On Fri, Jun 07, 2013 at 10:05:37AM -0700, Constantine A. Murenin wrote: On 6 June 2013 23:33, Fredrik Gustafsson iv...@iveqy.com wrote: On Thu, Jun 06, 2013 at 06:35:43PM -0700, Constantine A. Murenin wrote: I'm interested in running a web interface to this and other similar git repositories (FreeBSD and NetBSD git repositories are even much, much bigger). Software-wise, is there no way to make cold access for git-log and git-blame to be orders of magnitude less than ~5s, and warm access less than ~0.5s? The obvious way would be to cache the results. You can even put an That would do nothing to prevent slowness of the cold requests, which already run for 5s when completely cold. In fact, unless done right, it would actually slow things down, as lines would not necessarily show up as they're ready. You need to cache this _before_ the web-request. Don't let the web-request trigger a cache-update but a git push to the repository. update cache hook the git repositories to make the cache always be up to date. That's entirely inefficient. It'll probably take hours or days to pre-cache all the html pages with a naive wget and the list of all the files. Not a solution at all. (0.5s x 35k files = 5 hours for log/blame, plus another 5h of cpu time for blame/log) That's a one-time penalty. Why would that be a problem? And why is wget even mentioned? Did we misunderstood eachother? `wget` or `curl --head` would be used to trigger the caching. I don't understand how it's a one-time penalty. Noone wants to look at an old copy of the repository, so, pretty much, if, say, I want to have a gitweb of all 4 BSDs, updated daily, then, pretty much, even with lots of ram (e.g. to eliminate the cold-case 5s penalty, and reduce each page to 0.5s), on a quad-core box, I'd be kinda be lucky to complete a generation of all the pages within 12h or so, obviously using the machine at, or above, 50% capacity just for the caching. Or several days or even a couple of weeks on an Intel Atom or VIA Nano with 2GB of RAM or so. Obviously not acceptable, there has to be a better solution. One could, I guess, only regenerate the pages which have changed, but it still sounds like an ugly solution, where you'd have to be generating a list of files that have changed between one gen and the next, and you'd still have to have a very high cpu, cache and storage requirements. C. There's some dynamic web frontends like cgit and gitweb out there but there's also static ones like git-arr ( http://blitiri.com.ar/p/git-arr/ ) that might be more of an option to you. The concept for git-arr looks interesting, but it has neither blame nor log, so, it's kinda pointless, because the whole thing that's slow is exactly blame and log. There has to be some way to improve these matters. Noone wants to wait 5 seconds until a page is generated, we're not running enterprise software here, latency is important! C. Git's internal structures make just blame pretty expensive. There's nothing you really can do for it algoritm wise (as far as I know, if there was, people would already improved it). The solution here is to have a hot repository to speed up things. There's of course little things you can do. I imagine that using git repack in a sane way probably could speed things up, as well as git gc. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 10:20 AM, Junio C Hamano gits...@pobox.com wrote: Ramkumar Ramachandra artag...@gmail.com writes: I think Felipe is using the argument that perl is declining to answer the question why didn't you write git-related in perl instead?; that's it. A question which nobody asked, I presume? I think we heard enough from packaging folks that a new dependency is unwelcome. What are you talking about? Which are these packaging folks we heard from? Also we heard from no regular/high-value reviewers that they feel comfortable reviewing additions in Ruby. Correction; *current* regular/high-value reviewers. So at least for now, the conclusion is to take approach #1, i.e. somebody who finds related a good addition rewrites it in Perl to promote it out of contrib/ once the design issues settle (of course it is still a possibility that no such volunteer appears). Regardless of what you conclude, Perl still continues to die, and by clinging to a dying language, all we do is hurt the project. There's tons of people that are familiar with Git and Ruby, but these people are not in this mailing list because there's nothing for them to discuss, because Git doesn't use Ruby. By making conclusions based on the comments from people who do follow the mailing list *currently*, you are being biased towards the status quo. It's no surprise that you decided to keep the status quo. We could change, and we would probably receive a big influx of fresh contributors happy that they can contribute in their favorite language. But we won't do that, why? Because you already decided that's not going to happen, because you are making the false assumption that things in the future can only be like things have been in the past. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 2:00 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Ramkumar Ramachandra artag...@gmail.com writes: Whether it's based on POSIX is an implementation detail for the user. The real question is more command-line Vs GUI than POSIX/Win32. Some Linux users like GUI, some windows users use command-line. I tried IDE integration with EGIT, and quite frankly I ended-up doing all the Git stuff in a terminal next to Eclipse. I see. But isn't it possible to implement a CLI in libgit2 too, no? Yes (there have actually been several attempts at this like https://github.com/Romain-Geissler/git2 and https://github.com/vfr-nl/git2/), but there are a *lot* of stuff that are in git.git and not in libgit2. I'd love to see Git re-implemented on top of libgit2, but that's not going to happen tomorrow :-\. Specially not if we *always* keep the status quo, and don't make better use of C and scripting languages. One of the advantages of Ruby is that it can be very easily extended from C. I have never seen an easier way to write bindings than in Ruby. If we allowed Ruby to be in the core, it would make sense to create official Ruby bindings, and that would create an enormous motivation for libigit/libgit2 to be complete. But if we always keep the status quo, there will never be that much motivation for such an effort. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] completion: add deprecated __git_complete_file ()
77c130 (completion: clarify ls-tree, archive, show completion,
2013-06-02) removed __git_complete_file () because it had no callers
left in the file. However, to avoid breaking user scripts that may
depend on this, add it back as a deprecated alias.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Based on pu.
contrib/completion/git-completion.bash | 5 +
1 file changed, 5 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d0a9ba4..0fb81c9 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -489,6 +489,11 @@ __git_complete_revlist_file ()
esac
}
+# no callers; deprecated alias
+__git_complete_file ()
+{
+ __git_complete_revlist_file
+}
# __git_complete_index_file requires 1 argument:
# 1: the options to pass to ls-file
--
1.8.3.244.g98dd9db.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 10:25 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: Johannes Schindelin wrote: My initial reaction, too. It was hard enough to get Perl included with Git for Windows (because of that pesky Subversion dependency). Nevertheless, we had to do it, and we did it. That is not quite correct. *I* did it. Not *we*. And I will not do it again. That's fine, I can do it. I bet it will be easy. While at it, why not re-evaluate the whole msysgit approach? I bet we don't need a whole separate project just to create a Windows installer. I've written Windows installers before, it's very easy to do from Linux. Rewriting everything in C? Is anyone bored enough to pick up this task? Bourne shell is a great language for prototyping; git-rebase.sh (and friends), git-stash.sh, git-pull.sh are doing just fine. Sure, it makes sense to do heavy-lifting in C, and this is happening as it has always been happening (remember git-commit.sh?). If you followed the list emails, you'd know that Felipe is looking into delegating large portions of the work done by git-rebase.sh to sequencer.c. As you know, there are very good reasons why I do not follow those mails. To the detriment on the project. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
On Fri, Jun 07, 2013 at 11:41:07AM -0700, Junio C Hamano wrote: git log -Gcomplete_file -p contrib/completion found this one: commit 1d66ec587e7d903afdf12a81718772a9eadc15a1 Author: SZEDER Gábor sze...@ira.uka.de Date: Thu Mar 10 19:12:29 2011 +0100 bash: complete 'git diff ...brancTAB' (snip) Suggested-by: Junio C Hamano gits...@pobox.com Signed-off-by: SZEDER Gábor sze...@ira.uka.de Signed-off-by: Junio C Hamano gits...@pobox.com Now I do not recall suggesting it, and you (and I today after 2 years) may disagree with the rationale, but at least we can read what was the intended meaning, I think. See http://thread.gmane.org/gmane.comp.version-control.git/167728/focus=168838 I still agree with the rationale, considering that the new __git_complete_revlist_file() function for completing ref1...ref2:path is a nearly straight copy-paste from the then __git_complete_revlist() and __git_complete_file() including that 12 line long sed script. Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Thu, Jun 6, 2013 at 3:19 PM, David Lang da...@lang.hm wrote: On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote: David Lang wrote: Perl use may or may not be declining (depending on how you measure it), but are you really willing to take on the task of re-writing everything that's in Perl into another language and force all developers of scripts to learn that other language? what's the ROI of this? Let's not talk hypotheticals. git-svn.perl (+ perl/SVN/*.pl) is absolutely massive. It's an incredibly useful tool in that it actually works, and that there is nothing replacing it in the foreseeable future. This monster was written almost entirely by one brilliant person, and nobody is going to rewrite it. We don't start a huge discussion about what languages are approved before accepting such a contribution: if the contributor wants to write something in a dominant language (Perl in this case), and it's going to be useful, we merge it. End of story. Well, Felipe is saying that Perl is dieing and we should re-write everything that exists in Perl to Ruby. No, I said we should try to move away from Perl. Move stuff to C, shell scripts, and yeah, Ruby. Why are we discussing something that is indeterminate? It is impossible to foresee the future, but that is no reason to freeze _present_ development. and it's not a reason to throw away existing stuff based on the argument that Perl is dieing Who said anything about throwing away code? Nobody claimed that press coverage is a good metric. We can only talk about facts, and Felipe already showed you a TIOBE index graph. If you have overwhelming _evidence_ that Ruby is a weak language that will die soon, share it: otherwise, I see no value in this discussion. TIOBE index graph is press coverage as far as I'm concerned. I'm not saying that Ruby in particular has a fatal flaw, I'm just questioning the Perl is dead, re-write everything in Ruby mantra. The language that you choose to use when writing a new application is related to things related to that type of application. Ruby is not an extremely common language for sysadmins to use. Who said we need a language commonly used by sysadmins for our Git core? Perl remains a common language for these sorts of tasks, even if it's not used for user visible applications. Ruby is pretty much a replacement for Perl. For every task Perl is good, Ruby also is. Ruby's syntax even borrows from Perl. The difference is; Ruby is better for many more tasks that suck in Perl. Arguing that Perl is dieing, we need to abandon it is just wrong. Straw man. Nobody is arguing that. I said we should try to avoid it, not abandon it immediately. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: add deprecated __git_complete_file ()
Felipe Contreras wrote: This is fine by me, but at some point we need to decide how we should prefix the functions that are supposed to be used by external scripts. Yeah, I thought __ meant internal :/ Also, maybe we should start adding '# TODO remove in v2.0' so we remember to do that in v2.0. While at it, let's also clean up the deprecated zsh nonsense in git-completion.bash. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: add deprecated __git_complete_file ()
On Fri, Jun 7, 2013 at 2:29 PM, Ramkumar Ramachandra artag...@gmail.com wrote: Felipe Contreras wrote: This is fine by me, but at some point we need to decide how we should prefix the functions that are supposed to be used by external scripts. Yeah, I thought __ meant internal :/ Also, maybe we should start adding '# TODO remove in v2.0' so we remember to do that in v2.0. While at it, let's also clean up the deprecated zsh nonsense in git-completion.bash. And the _git _gitk compatibility wrappers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
On Thu, Jun 06, 2013 at 06:05:44PM -0700, Junio C Hamano wrote: SZEDER Gábor sze...@ira.uka.de writes: On Thu, Jun 06, 2013 at 03:41:08PM -0700, Junio C Hamano wrote: * rr/complete-difftool (2013-06-03) 2 commits (merged to 'next' on 2013-06-04 at 01c7611) + completion: clarify ls-tree, archive, show completion + completion: difftool takes both revs and files Update command line completion (in contrib/) to use a better named completion helper function for commands that take revisions and paths. Will merge to 'master'. This should not be merged to master as is; the one at the top because of the reasons given in $gmane/226272, the one at the bottom because of the misleading commit message (__git_complete_file() always completed refs first as part of the ref:file notation, so it worked just fine except for the ref1...ref2 notation; the real reason for calling __git_complete_revlist_file() for difftool is to make clear that difftool takes ref1...ref2:file, too). Oops. It is too late to amend the log messages now, but at least a follow-up patch can fix the breakage by adding __git_complete_file() back. Would you mind doing that? Is it in master already? Am I missing something? Wouldn't it be cleaner to revert those two patches from next and apply this instead? -- 8 -- From: SZEDER Gábor sze...@ira.uka.de Subject: [PATCH] completion: be explicit about revlist completion for difftool and show The completion functions for 'git difftool' and 'git show' call __git_complete_file() to support completion of the 'ref:path' notation. However, these two commands also understand the 'ref1..ref2:path' notation, the completion of which we happen to support accidentaly, because nowadays __git_complete_file() is a wrapper around __git_complete_revlist_file(). Let's be explicit about it and call __git_complete_revlist_file() directly. Signed-off-by: SZEDER Gábor sze...@ira.uka.de --- contrib/completion/git-completion.bash | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 56c52c66..fd9a1d5f 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1211,7 +1211,7 @@ _git_difftool () return ;; esac - __git_complete_file + __git_complete_revlist_file } __git_fetch_options= @@ -2277,7 +2277,7 @@ _git_show () return ;; esac - __git_complete_file + __git_complete_revlist_file } _git_show_branch () -- 1.8.0.220.g4d14ece -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/8] Rebase topology test
Am 07.06.2013 08:11, schrieb Martin von Zweigbergk: Changes since v5: * Improved test_linear_range * Changed TODOs to be about consistency, not --topo-order Martin von Zweigbergk (7): add simple tests of consistency across rebase types add tests for rebasing with patch-equivalence present add tests for rebasing of empty commits add tests for rebasing root add tests for rebasing merged history t3406: modernize style tests: move test for rebase messages from t3400 to t3406 I looked at the interdiff to v3 and have nothing to add. Well done! Thanks. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Felipe Contreras wrote: While at it, why not re-evaluate the whole msysgit approach? I bet we don't need a whole separate project just to create a Windows installer. I've written Windows installers before, it's very easy to do from Linux. Yeah, taking the pain out of msysgit packaging would be a great way to counter this new-dependency-fud. The main problem, as mm pointed out is subversion + perlxs [1]. Any idea how to tackle that? [1]: https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
SZEDER Gábor sze...@ira.uka.de writes: Now I do not recall suggesting it, and you (and I today after 2 years) may disagree with the rationale, but at least we can read what was the intended meaning, I think. See http://thread.gmane.org/gmane.comp.version-control.git/167728/focus=168838 I still agree with the rationale,... Thanks for a pointer. I think what I was suggesting was slightly different in that I was hoping to see a single helper that knows to complete to object names (possibly including trees/blobs with the treeish:path notation), ranges, and pathnames (not treeish:path notation) until it sees a -- and then complete only to pathnames. It can be improved by teaching the unified one that some command like log can never take treeish:path but only committishes, some command take individual object names but never ranges, and/or details like that. But I still agree that git log HEAD:dirTAB that completes to a blob or a tree object name is not an issue (because what was before TAB cannot possibly name anything git log would appreciate), even though it might not be ideal. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Ramkumar Ramachandra wrote: commit a lot of good ruby code to contrib* Oh, by the way: I have a project idea. There's this really popular project called hub[1] that has an implementation of the GitHub API in ruby. Unfortunately, it's a terrible piece of software because it creates an extra layer of indirection by putting a ruby wrapper on top of git, and this slows git down: I cannot tolerate even a microsecond of delay in git. Maybe it's worth ripping out the GitHub API implementation and writing some useful subcommands? [1]: https://github.com/defunkt/hub -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
SZEDER Gábor wrote: because nowadays __git_complete_file() is a wrapper around __git_complete_revlist_file(). What? It was never anything different from a poorly-named alias for __git_complete_revlist_file(). You have already agreed that __git_complete_file() is a horrible name, so why not deprecate it? Whom is this confusion benefiting, and how is it any cleaner? If you're arguing about expanding __git_complete_file(), don't do that: just write a new function and give it a proper name. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
Felipe Contreras felipe.contre...@gmail.com writes: I think we heard enough from packaging folks that a new dependency is unwelcome. What are you talking about? Which are these packaging folks we heard from? Dscho is one of the primary people behind msysgit effort, and I consulted with others from the circle with an draft before I sent the message to the list for sanity checking (fearing that I may be worrying about adding new dependencies needlessly). Jonathan packages git for Debian and he is negative on adding new dependency needlessly. It was unexpected that we hear from a pkgsrc person but the response was also negative. Also we heard from no regular/high-value reviewers that they feel comfortable reviewing additions in Ruby. Correction; *current* regular/high-value reviewers. That is exactly what I meant. The code review is not only about following best practices in the implementation language. If somebody who is an expert in a language we do not currently depend on, but who does not know how the parts of Git are supposed to fit together enough to judge the soundness of the design of new code written in that new language, or does not know how the tests, documentation and log messages are supposed to written around here, that person cannot be the only reviewer for changes written in that language to ensure quality standard. The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Administrivia] On ruby and contrib/
On Fri, Jun 7, 2013 at 2:55 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I think we heard enough from packaging folks that a new dependency is unwelcome. What are you talking about? Which are these packaging folks we heard from? Dscho is one of the primary people behind msysgit effort, and I consulted with others from the circle with an draft before I sent the message to the list for sanity checking (fearing that I may be worrying about adding new dependencies needlessly). He said he won't do it, but I said I would. Doesn't that solve the problem? Jonathan packages git for Debian and he is negative on adding new dependency needlessly. I don't see any comment from Jonathan. It was unexpected that we hear from a pkgsrc person but the response was also negative. You mean Greg Troxel? He is only one of the persons that help, and I did shut down his argument, didn't I? Also we heard from no regular/high-value reviewers that they feel comfortable reviewing additions in Ruby. Correction; *current* regular/high-value reviewers. That is exactly what I meant. The code review is not only about following best practices in the implementation language. If somebody who is an expert in a language we do not currently depend on, but who does not know how the parts of Git are supposed to fit together enough to judge the soundness of the design of new code written in that new language, or does not know how the tests, documentation and log messages are supposed to written around here, that person cannot be the only reviewer for changes written in that language to ensure quality standard. The reviewer pool for code written in a new language _must_ be seeded by some from the current set of reviewers whose judgement I/we can trust. By that standard nothing will ever change. Ever. Even twenty years from now, you will still only trust people that are familiar with shell, Perl, and C. Because the only way to gain your trust, is by being proficient in shell, Perl, and C. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] Turn double-negated expressions into simple expressions
On Fri, Jun 7, 2013 at 1:04 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Le 07/06/2013 06:12, Eric Sunshine a écrit :
On Thu, Jun 6, 2013 at 3:34 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
} elsif ($cmd[0] eq import) {
- die(Invalid arguments for import\n) unless
($cmd[1] ne !defined($cmd[2]));
+ die(Invalid arguments for import\n) if ($cmd[1]
eq || defined($cmd[2]));
mw_import($cmd[1]);
} elsif ($cmd[0] eq option) {
- die(Too many arguments for option\n) unless
($cmd[1] ne $cmd[2] ne !defined($cmd[3]));
+ die(Too many arguments for option\n) if ($cmd[1]
eq || $cmd[2] eq || defined($cmd[3]));
Not new in this patch, but isn't this diagnostic misleading? It will
(falsely) claim too many arguments if $cmd[1] or $cmd[2] is an empty
string. Perhaps it should be reworded like the 'import' diagnostic and
say Invalid arguments for option.
We could even be more precise and separate the cases, i.e., die(Too
many arguments) when too many arguments are defined and die(Invalid
arguments) when there are empty strings.
Not sure if I should integrate it in this patch, though.
If you do choose to be more precise, it should be done as a separate
patch. Each conceptually distinct change should have its own patch.
Doing so makes changes easier to review and (generally) easier to
cherry-pick. For example, in this particular case, simplify
doubly-negated expressions is quite conceptually distinct from emit
more precise diagnostics. (Textually the changes may happen to
overlap, but conceptually they are unrelated.)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/9] cherry-pick: add --skip-empty option
On Thu, Jun 6, 2013 at 2:21 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Thu, Jun 6, 2013 at 1:30 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Pretty much what it says on the tin. And a bit more, isn't it? The --keep-redundant-commits option implies the --allow-empty option and it was perfectly acceptable to give both. By making sure that only at most one of -k-r-d, -a-e or -s-e is given, this forbids that usage. It is implied so there is no *need* to give it redundantly is different from It is implied so you shouldn't give it redundantly. Remove that line then. That's what the submitter does. Apparently the submitter does everything. It seems sending 800 patches in the past 3 months is not enough work for you. And what's the point? If nobody is interested in shifting from shell scripts to C, neither am I. Consider this series abandoned. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] Turn double-negated expressions into simple expressions
Le 07/06/2013 22:25, Eric Sunshine a écrit : If you do choose to be more precise, it should be done as a separate patch. Each conceptually distinct change should have its own patch. Doing so makes changes easier to review and (generally) easier to cherry-pick. For example, in this particular case, simplify doubly-negated expressions is quite conceptually distinct from emit more precise diagnostics. (Textually the changes may happen to overlap, but conceptually they are unrelated.) OK, I will do another patch. -- Célestin Matte -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Trivial patches
Felipe Contreras (3): sequencer: trivial fix test: improve rebase -q test submodule: remove unnecessary check sequencer.c | 7 +-- submodule.c | 5 ++--- t/t3400-rebase.sh | 1 + 3 files changed, 8 insertions(+), 5 deletions(-) -- 1.8.3.698.g079b096 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] submodule: remove unnecessary check
read_cache() already does that check. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- submodule.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/submodule.c b/submodule.c index ad476ce..8685424 100644 --- a/submodule.c +++ b/submodule.c @@ -603,9 +603,8 @@ int fetch_populated_submodules(const struct argv_array *options, if (!work_tree) goto out; - if (!the_index.initialized) - if (read_cache() 0) - die(index file corrupt); + if (read_cache() 0) + die(index file corrupt); argv_array_push(argv, fetch); for (i = 0; i options-argc; i++) -- 1.8.3.698.g079b096 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] sequencer: trivial fix
We should free objects before leaving.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/sequencer.c b/sequencer.c
index ab6f8a7..7eeae2f 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -626,12 +626,15 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
rerere(opts-allow_rerere_auto);
} else {
int allow = allow_empty(opts, commit);
- if (allow 0)
- return allow;
+ if (allow 0) {
+ res = allow;
+ goto leave;
+ }
if (!opts-no_commit)
res = run_git_commit(defmsg, opts, allow);
}
+leave:
free_message(msg);
free(defmsg);
--
1.8.3.698.g079b096
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] test: improve rebase -q test
Let's show the output so it's clear why it failed.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t3400-rebase.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b58fa1a..fb39531 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -185,6 +185,7 @@ test_expect_success 'default to @{upstream} when upstream
arg is missing' '
test_expect_success 'rebase -q is quiet' '
git checkout -b quiet topic
git rebase -q master output.out 21
+ cat output.out
test ! -s output.out
'
--
1.8.3.698.g079b096
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] completion: add deprecated __git_complete_file ()
Ramkumar Ramachandra artag...@gmail.com writes: 77c130 (completion: clarify ls-tree, archive, show completion, 2013-06-02) removed __git_complete_file () because it had no callers left in the file. However, to avoid breaking user scripts that may depend on this, add it back as a deprecated alias. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- Based on pu. Will queue; thanks. With this, I think it will be safe to push the series in question to 'master'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: fix problem causing erroneous project list
On Wed, Jun 5, 2013 at 9:17 PM, Junio C Hamano gits...@pobox.com wrote:
Charles McGarvey chazmcgar...@brokenzipper.com writes:
The bug is manifest when running gitweb in a persistent process (e.g.
FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
includes the searchtext parameter (i.e. s), subsequent requests using
the project_list action--which is the default action--and without
a searchtext parameter will be filtered by the searchtext value of the
first request. This is because the value of the $search_regexp global
(the value of which is based on the searchtext parameter) is currently
being persisted between requests.
Instead, clear $search_regexp before dispatching each request.
Signed-off-by: Charles McGarvey chazmcgar...@brokenzipper.com
Acked-by: Jakub Narebski jna...@gmail.com
---
I don't think there are currently any persistent-process gitweb tests to
copy from, so writing a test for this seems to be non-trivial.
Well, there is Plack::Test, and gitweb supports running as PSGI app.
Though all such test would have to be under new PLACK or PSGI
prerequisite.
The problem description makes sense to me, and clearing with undef
is in line with the case where the CGI is run for the first time, so
I think this patch is correct.
Will wait for a while to give Jakub some time to comment on (like:
Ack ;-) and then apply. Thanks.
By the way, I looked at how $search_regexp is used in the code:
How $search_regexp is used does not matter. What was intended
(but was not implemented) is for $search_regexp to matter and to
be used only if $searchtext is defined. $searchtext is reset on each
request, so $search_regexp should be also reset... like in Charles's
patch.
Anyway in the analysis below we need to check if code checks
$searchtext first.
* esc_html_match_hl and esc_html_match_hl__chopped (called from
git_project_list_rows, for example) want to have undef; an
empty string will not do.
* search_projects_list (called from git_project_list_body)
x git_search_files and git_search_grep_body assume that
$search_regexp can be interpolated in m//, which is not very
nice. They want an empty string.
But both git_search_files() and git_search_grep_body() are run from
git_search(), which dies (returns HTTP 400 Text field is empty error)
if $searchtext is not defined; if $searchtext is defined then $search_regexp
is string and is never undef.
So as an independent fix, the two subs may want to be fixed if we
want to be undef clean. Or am I missing something? Jakub, isn't
this kind of undef reference t9500 was designed to catch?
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 80950c0..8d69ada 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1086,7 +1086,7 @@ sub evaluate_and_validate_params {
our $search_use_regexp = $input_params{'search_use_regexp'};
our $searchtext = $input_params{'searchtext'};
- our $search_regexp;
+ our $search_regexp = undef;
if (defined $searchtext) {
if (length($searchtext) 2) {
die_error(403, At least two characters are required
for search parameter);
--
Jakub Narebski
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jun 2013, #03; Thu, 6)
On Fri, Jun 07, 2013 at 12:46:25PM -0700, Junio C Hamano wrote: Thanks for a pointer. I think what I was suggesting was slightly different in that I was hoping to see a single helper that knows to complete to object names (possibly including trees/blobs with the treeish:path notation), ranges, and pathnames (not treeish:path notation) until it sees a -- and then complete only to pathnames. We already got that except the completion of pathnames before --, and I don't know how that could be done properly for commands taking both refs and paths. Just consider git diff git.c git diff master git.c git diff master next git.c We can't guess whether the user wants refs or paths when he first hits tab after 'git diff ', not even after 'git diff master '. I definitely don't want to see refs and paths all mixed up. As for the _single_ helper: I think it has some value that we have different helper functions and we can indicate whether a certain git command can take a ref or ref:path or ref1...ref2 or even ref1..ref2:path by calling the appropriate helper function (however badly it might have been named), even if all these functions happen to boil down to a single implementation. Gábor -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/10] test-chmtime: Fix exit code on Windows
MinGW's bash does not recognize an exit code -1 as failure. See also
47e3de0e (MinGW: truncate exit()'s argument to lowest 8 bits) and 2488df84
(builtin run_command: do not exit with -1). Exit code 1 is good enough.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
test-chmtime.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/test-chmtime.c b/test-chmtime.c
index 02b42ba..2e601a8 100644
--- a/test-chmtime.c
+++ b/test-chmtime.c
@@ -84,7 +84,7 @@ int main(int argc, const char *argv[])
if (stat(argv[i], sb) 0) {
fprintf(stderr, Failed to stat %s: %s\n,
argv[i], strerror(errno));
- return -1;
+ return 1;
}
#ifdef WIN32
@@ -92,7 +92,7 @@ int main(int argc, const char *argv[])
chmod(argv[i], sb.st_mode | S_IWUSR)) {
fprintf(stderr, Could not make user-writable %s: %s,
argv[i], strerror(errno));
- return -1;
+ return 1;
}
#endif
@@ -107,7 +107,7 @@ int main(int argc, const char *argv[])
if (utb.modtime != sb.st_mtime utime(argv[i], utb) 0) {
fprintf(stderr, Failed to modify time on %s: %s\n,
argv[i], strerror(errno));
- return -1;
+ return 1;
}
}
@@ -115,5 +115,5 @@ int main(int argc, const char *argv[])
usage:
fprintf(stderr, usage: %s %s\n, argv[0], usage_str);
- return -1;
+ return 1;
}
--
1.8.3.rc1.32.g8b61cbb
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/10] t3010: modernize style
In particular: - move test preparations inside test_expect_success - place test description on the test_expect_success line - indent with a tab Signed-off-by: Johannes Sixt j...@kdbg.org --- t/t3010-ls-files-killed-modified.sh | 123 ++-- 1 file changed, 61 insertions(+), 62 deletions(-) diff --git a/t/t3010-ls-files-killed-modified.sh b/t/t3010-ls-files-killed-modified.sh index 95671c2..2d0ff2d 100755 --- a/t/t3010-ls-files-killed-modified.sh +++ b/t/t3010-ls-files-killed-modified.sh @@ -37,71 +37,70 @@ modified without reporting path9 and path10. ' . ./test-lib.sh -date path0 -if test_have_prereq SYMLINKS -then - ln -s xyzzy path1 -else - date path1 -fi -mkdir path2 path3 -date path2/file2 -date path3/file3 -: path7 -date path8 -: path9 -date path10 -test_expect_success \ -'git update-index --add to add various paths.' \ -git update-index --add -- path0 path1 path?/file? path7 path8 path9 path10 - -rm -fr path? ;# leave path10 alone -date path2 -if test_have_prereq SYMLINKS -then - ln -s frotz path3 - ln -s nitfol path5 -else - date path3 - date path5 -fi -mkdir path0 path1 path6 -date path0/file0 -date path1/file1 -date path6/file6 -date path7 -: path8 -: path9 -touch path10 +test_expect_success 'git update-index --add to add various paths.' ' + date path0 + if test_have_prereq SYMLINKS + then + ln -s xyzzy path1 + else + date path1 + fi + mkdir path2 path3 + date path2/file2 + date path3/file3 + : path7 + date path8 + : path9 + date path10 + git update-index --add -- path0 path1 path?/file? path7 path8 path9 path10 + rm -fr path?# leave path10 alone +' -test_expect_success \ -'git ls-files -k to show killed files.' \ -'git ls-files -k .output' -cat .expected EOF -path0/file0 -path1/file1 -path2 -path3 -EOF +test_expect_success 'git ls-files -k to show killed files.' ' + date path2 + if test_have_prereq SYMLINKS + then + ln -s frotz path3 + ln -s nitfol path5 + else + date path3 + date path5 + fi + mkdir path0 path1 path6 + date path0/file0 + date path1/file1 + date path6/file6 + date path7 + : path8 + : path9 + touch path10 + git ls-files -k .output +' -test_expect_success \ -'validate git ls-files -k output.' \ -'test_cmp .expected .output' +test_expect_success 'validate git ls-files -k output.' ' + cat .expected -\EOF + path0/file0 + path1/file1 + path2 + path3 + EOF + test_cmp .expected .output +' -test_expect_success \ -'git ls-files -m to show modified files.' \ -'git ls-files -m .output' -cat .expected EOF -path0 -path1 -path2/file2 -path3/file3 -path7 -path8 -EOF +test_expect_success 'git ls-files -m to show modified files.' ' + git ls-files -m .output +' -test_expect_success \ -'validate git ls-files -m output.' \ -'test_cmp .expected .output' +test_expect_success 'validate git ls-files -m output.' ' + cat .expected -\EOF + path0 + path1 + path2/file2 + path3/file3 + path7 + path8 + EOF + test_cmp .expected .output +' test_done -- 1.8.3.rc1.32.g8b61cbb -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/10] t3030: use test_ln_s_add to remove SYMLINKS prerequisite
The test cases include many corner-cases of merge-recursive's behavior, some of them involve type changes and symbolic links. All cases, including those that are protected by SYMLINKS check only whether the result of merge-recursive is correctly stored in the database and the index; the file system is not investigated. Use test_ln_s_add to enter a symbolic link in the index in the test setup and run the tests without the SYMLINKS prerequisite. Notice that one test that has the SYMLINKS protection removed is an expect_failure. There is a possibility that the test fails differently depending on whether SYMLINKS is present or not; but this is not the case presently. Signed-off-by: Johannes Sixt j...@kdbg.org --- t/t3030-merge-recursive.sh | 62 +++--- 1 file changed, 26 insertions(+), 36 deletions(-) diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh index a5e3da7..2f96100 100755 --- a/t/t3030-merge-recursive.sh +++ b/t/t3030-merge-recursive.sh @@ -25,10 +25,7 @@ test_expect_success 'setup 1' ' git branch submod git branch copy git branch rename - if test_have_prereq SYMLINKS - then - git branch rename-ln - fi + git branch rename-ln echo hello a cp a d/e @@ -260,16 +257,12 @@ test_expect_success 'setup 8' ' git add e test_tick git commit -m rename a-e - if test_have_prereq SYMLINKS - then - git checkout rename-ln - git mv a e - ln -s e a - git add a e - test_tick - git commit -m rename a-e, symlink a-e - oln=`printf e | git hash-object --stdin` - fi + git checkout rename-ln + git mv a e + test_ln_s_add e a + test_tick + git commit -m rename a-e, symlink a-e + oln=`printf e | git hash-object --stdin` ' test_expect_success 'setup 9' ' @@ -569,28 +562,25 @@ test_expect_success 'merge-recursive copy vs. rename' ' test_cmp expected actual ' -if test_have_prereq SYMLINKS -then - test_expect_failure 'merge-recursive rename vs. rename/symlink' ' - - git checkout -f rename - git merge rename-ln - ( git ls-tree -r HEAD ; git ls-files -s ) actual - ( - echo 12 blob $oln a - echo 100644 blob $o0 b - echo 100644 blob $o0 c - echo 100644 blob $o0 d/e - echo 100644 blob $o0 e - echo 12 $oln 0 a - echo 100644 $o0 0 b - echo 100644 $o0 0 c - echo 100644 $o0 0 d/e - echo 100644 $o0 0 e - ) expected - test_cmp expected actual - ' -fi +test_expect_failure 'merge-recursive rename vs. rename/symlink' ' + + git checkout -f rename + git merge rename-ln + ( git ls-tree -r HEAD ; git ls-files -s ) actual + ( + echo 12 blob $oln a + echo 100644 blob $o0 b + echo 100644 blob $o0 c + echo 100644 blob $o0 d/e + echo 100644 blob $o0 e + echo 12 $oln 0 a + echo 100644 $o0 0 b + echo 100644 $o0 0 c + echo 100644 $o0 0 d/e + echo 100644 $o0 0 e + ) expected + test_cmp expected actual +' test_done -- 1.8.3.rc1.32.g8b61cbb -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/10] t3509, t4023, t4114: use test_ln_s_add to remove SYMLINKS prerequisite
In t4023 and t4114, we have to remove the entries using 'git rm' because
otherwise the entries that must turn from symbolic links to regular files
would stay symbolic links in the index. For the same reason, we have to
use 'git mv' instead of plain 'mv' in t3509.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/t3509-cherry-pick-merge-df.sh | 12 +---
t/t4023-diff-rename-typechange.sh | 28 ++--
t/t4114-apply-typechange.sh | 29 ++---
3 files changed, 33 insertions(+), 36 deletions(-)
diff --git a/t/t3509-cherry-pick-merge-df.sh b/t/t3509-cherry-pick-merge-df.sh
index df921d1..a5b6a5f 100755
--- a/t/t3509-cherry-pick-merge-df.sh
+++ b/t/t3509-cherry-pick-merge-df.sh
@@ -10,17 +10,15 @@ test_expect_success 'Initialize repository' '
git commit -m a
'
-test_expect_success SYMLINKS 'Setup rename across paths each below D/F
conflicts' '
+test_expect_success 'Setup rename across paths each below D/F conflicts' '
mkdir b
- ln -s ../a b/a
- git add b
+ test_ln_s_add ../a b/a
git commit -m b
git checkout -b branch
rm b/a
- mv a b/a
- ln -s b/a a
- git add .
+ git mv a b/a
+ test_ln_s_add b/a a
git commit -m swap
f1
@@ -28,7 +26,7 @@ test_expect_success SYMLINKS 'Setup rename across paths each
below D/F conflicts
git commit -m f1
'
-test_expect_success SYMLINKS 'Cherry-pick succeeds with rename across D/F
conflicts' '
+test_expect_success 'Cherry-pick succeeds with rename across D/F conflicts' '
git reset --hard
git checkout master^0
git cherry-pick branch
diff --git a/t/t4023-diff-rename-typechange.sh
b/t/t4023-diff-rename-typechange.sh
index 5d20acf..55d549f 100755
--- a/t/t4023-diff-rename-typechange.sh
+++ b/t/t4023-diff-rename-typechange.sh
@@ -4,44 +4,44 @@ test_description='typechange rename detection'
. ./test-lib.sh
-test_expect_success SYMLINKS setup '
+test_expect_success setup '
rm -f foo bar
cat $TEST_DIRECTORY/../COPYING foo
- ln -s linklink bar
- git add foo bar
+ test_ln_s_add linklink bar
+ git add foo
git commit -a -m Initial
git tag one
- rm -f foo bar
+ git rm -f foo bar
cat $TEST_DIRECTORY/../COPYING bar
- ln -s linklink foo
- git add foo bar
+ test_ln_s_add linklink foo
+ git add bar
git commit -a -m Second
git tag two
- rm -f foo bar
+ git rm -f foo bar
cat $TEST_DIRECTORY/../COPYING foo
git add foo
git commit -a -m Third
git tag three
mv foo bar
- ln -s linklink foo
- git add foo bar
+ test_ln_s_add linklink foo
+ git add bar
git commit -a -m Fourth
git tag four
# This is purely for sanity check
- rm -f foo bar
+ git rm -f foo bar
cat $TEST_DIRECTORY/../COPYING foo
cat $TEST_DIRECTORY/../Makefile bar
git add foo bar
git commit -a -m Fifth
git tag five
- rm -f foo bar
+ git rm -f foo bar
cat $TEST_DIRECTORY/../Makefile foo
cat $TEST_DIRECTORY/../COPYING bar
git add foo bar
@@ -50,7 +50,7 @@ test_expect_success SYMLINKS setup '
'
-test_expect_success SYMLINKS 'cross renames to be detected for regular files' '
+test_expect_success 'cross renames to be detected for regular files' '
git diff-tree five six -r --name-status -B -M | sort actual
{
@@ -61,7 +61,7 @@ test_expect_success SYMLINKS 'cross renames to be detected
for regular files' '
'
-test_expect_success SYMLINKS 'cross renames to be detected for typechange' '
+test_expect_success 'cross renames to be detected for typechange' '
git diff-tree one two -r --name-status -B -M | sort actual
{
@@ -72,7 +72,7 @@ test_expect_success SYMLINKS 'cross renames to be detected
for typechange' '
'
-test_expect_success SYMLINKS 'moves and renames' '
+test_expect_success 'moves and renames' '
git diff-tree three four -r --name-status -B -M | sort actual
{
diff --git a/t/t4114-apply-typechange.sh b/t/t4114-apply-typechange.sh
index f12826f..ebadbc3 100755
--- a/t/t4114-apply-typechange.sh
+++ b/t/t4114-apply-typechange.sh
@@ -9,20 +9,19 @@ test_description='git apply should not get confused with type
changes.
. ./test-lib.sh
-test_expect_success SYMLINKS 'setup repository and commits' '
+test_expect_success 'setup repository and commits' '
echo hello world foo
echo hi planet bar
git update-index --add foo bar
git commit -m initial
git branch initial
rm -f foo
- ln -s bar foo
- git update-index foo
+ test_ln_s_add bar foo
git commit -m foo symlinked to bar
git branch foo-symlinked-to-bar
- rm
[PATCH v2 00/10] Increase test coverage on Windows by removing SYMLINKS from many tests
Many tests that involve symbolic links actually check only whether our algorithms are correct by investigating the contents of the object database and the index. Only some of them check the filesystem. This series introduces a function test_ln_s_add that inserts a symbolic link in the index even if the filesystem does not support symbolic links. By using this function, many more tests can be run when the filesystem does not have symblic links, aka Windows. Changes since v1: - Ripped out test_ln_s and corresponding conversions; they were dubious. - There are no changes to t2100 anymore; the corresponding modernization patch is gone. - Moved the t4011 change from the trivial cases to its own patch. It still contains the effects of the former test_ln_s, but open-coded and with a comment. Johannes Sixt (10): test-chmtime: Fix exit code on Windows t3010: modernize style tests: introduce test_ln_s_add tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases) t: use test_ln_s_add to remove SYMLINKS prerequisite t3030: use test_ln_s_add to remove SYMLINKS prerequisite t3100: use test_ln_s_add to remove SYMLINKS prerequisite t3509, t4023, t4114: use test_ln_s_add to remove SYMLINKS prerequisite t6035: use test_ln_s_add to remove SYMLINKS prerequisite t4011: remove SYMLINKS prerequisite t/README | 14 t/t-basic.sh | 39 +++ t/t1004-read-tree-m-u-wf.sh| 7 +- t/t2001-checkout-cache-clash.sh| 7 +- t/t2004-checkout-cache-temp.sh | 5 +- t/t2007-checkout-symlink.sh| 12 ++-- t/t2021-checkout-overwrite.sh | 12 ++-- t/t2200-add-update.sh | 5 +- t/t3010-ls-files-killed-modified.sh| 118 - t/t3030-merge-recursive.sh | 62 - t/t3100-ls-tree-restrict.sh| 42 +--- t/t3509-cherry-pick-merge-df.sh| 12 ++-- t/t3700-add.sh | 15 ++--- t/t3903-stash.sh | 39 --- t/t4008-diff-break-rewrite.sh | 12 ++-- t/t4011-diff-symlink.sh| 35 +++--- t/t4023-diff-rename-typechange.sh | 28 t/t4030-diff-textconv.sh | 8 +-- t/t4114-apply-typechange.sh| 29 t/t4115-apply-symlink.sh | 10 ++- t/t4122-apply-symlink-inside.sh| 8 +-- t/t6035-merge-dir-to-symlink.sh| 73 t/t7001-mv.sh | 18 +++-- t/t7607-merge-overwrite.sh | 5 +- t/t8006-blame-textconv.sh | 14 ++-- t/t8007-cat-file-textconv.sh | 10 ++- t/t9350-fast-export.sh | 5 +- t/t9500-gitweb-standalone-no-errors.sh | 15 ++--- t/test-lib-functions.sh| 17 + test-chmtime.c | 8 +-- 30 files changed, 351 insertions(+), 333 deletions(-) -- 1.8.3.rc1.32.g8b61cbb -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/10] t4011: remove SYMLINKS prerequisite
The part of the test that is about symbolic links in the index does not require that the corresponding file system entry is actually a symbolic link. Use test_ln_s_add to insert a symbolic link in the index. When the file system does not support symbolic links, we actually have a regular file in the worktree, which we can update as if it were a symbolic link. diff-index picks up the symbolic link property from the index. Signed-off-by: Johannes Sixt j...@kdbg.org --- t/t4011-diff-symlink.sh | 35 +-- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh index f0d5041..13e7f62 100755 --- a/t/t4011-diff-symlink.sh +++ b/t/t4011-diff-symlink.sh @@ -9,7 +9,7 @@ test_description='Test diff of symlinks. . ./test-lib.sh . $TEST_DIRECTORY/diff-lib.sh -test_expect_success SYMLINKS 'diff new symlink and file' ' +test_expect_success 'diff new symlink and file' ' cat expected -\EOF diff --git a/frotz b/frotz new file mode 12 @@ -27,22 +27,25 @@ test_expect_success SYMLINKS 'diff new symlink and file' ' @@ -0,0 +1 @@ +xyzzy EOF - ln -s xyzzy frotz - echo xyzzy nitfol + + # the empty tree git update-index tree=$(git write-tree) - git update-index --add frotz nitfol + + test_ln_s_add xyzzy frotz + echo xyzzy nitfol + git update-index --add nitfol GIT_DIFF_OPTS=--unified=0 git diff-index -M -p $tree current compare_diff_patch expected current ' -test_expect_success SYMLINKS 'diff unchanged symlink and file' ' +test_expect_success 'diff unchanged symlink and file' ' tree=$(git write-tree) git update-index frotz nitfol test -z $(git diff-index --name-only $tree) ' -test_expect_success SYMLINKS 'diff removed symlink and file' ' +test_expect_success 'diff removed symlink and file' ' cat expected -\EOF diff --git a/frotz b/frotz deleted file mode 12 @@ -66,12 +69,18 @@ test_expect_success SYMLINKS 'diff removed symlink and file' ' compare_diff_patch expected current ' -test_expect_success SYMLINKS 'diff identical, but newly created symlink and file' ' +test_expect_success 'diff identical, but newly created symlink and file' ' expected rm -f frotz nitfol echo xyzzy nitfol test-chmtime +10 nitfol - ln -s xyzzy frotz + if test_have_prereq SYMLINKS + then + ln -s xyzzy frotz + else + printf xyzzy frotz + # the symlink property propagates from the index + fi git diff-index -M -p $tree current compare_diff_patch expected current @@ -80,7 +89,7 @@ test_expect_success SYMLINKS 'diff identical, but newly created symlink and file compare_diff_patch expected current ' -test_expect_success SYMLINKS 'diff different symlink and file' ' +test_expect_success 'diff different symlink and file' ' cat expected -\EOF diff --git a/frotz b/frotz index 7c465af..df1db54 12 @@ -100,7 +109,13 @@ test_expect_success SYMLINKS 'diff different symlink and file' ' +yxyyz EOF rm -f frotz - ln -s yxyyz frotz + if test_have_prereq SYMLINKS + then + ln -s yxyyz frotz + else + printf yxyyz frotz + # the symlink property propagates from the index + fi echo yxyyz nitfol git diff-index -M -p $tree current compare_diff_patch expected current -- 1.8.3.rc1.32.g8b61cbb -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/10] t0000: use test_ln_s_add to remove SYMLINKS prerequisite
t-basic hard-codes many object IDs. To cater to file systems that do
not support symbolic links, different IDs are used depending on the
SYMLINKS prerequisite. But we can observe the symbolic links are only
needed to generate index entries. Use test_ln_s_add to generate the
index entries and get rid of explicit SYMLINKS checks.
This undoes the special casing introduced in this test by 704a3143
(Use prerequisite tags to skip tests that depend on symbolic links,
2009-03-04).
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/t-basic.sh | 39 ++-
1 file changed, 10 insertions(+), 29 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index cefe33d..0f13180 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -367,22 +367,6 @@ test_expect_success 'validate object ID of a known tree' '
# Various types of objects
-# Some filesystems do not support symblic links; on such systems
-# some expected values are different
-if test_have_prereq SYMLINKS
-then
- expectfilter=cat
- expectedtree=087704a96baf1c2d1c869a8b084481e121c88b5b
- expectedptree1=21ae8269cacbe57ae09138dcc3a2887f904d02b3
- expectedptree2=3c5e5399f3a333eddecce7a9b9465b63f65f51e2
-else
- expectfilter='grep -v sym'
- expectedtree=8e18edf7d7edcf4371a3ac6ae5f07c2641db7c46
- expectedptree1=cfb8591b2f65de8b8cc1020cd7d9e67e7793b325
- expectedptree2=ce580448f0148b985a513b693fdf7d802cacb44f
-fi
-
-
test_expect_success 'adding various types of objects with git update-index
--add' '
mkdir path2 path3 path3/subp3
paths=path0 path2/file2 path3/file3 path3/subp3/file3
@@ -390,10 +374,7 @@ test_expect_success 'adding various types of objects with
git update-index --add
for p in $paths
do
echo hello $p $p || exit 1
- if test_have_prereq SYMLINKS
- then
- ln -s hello $p ${p}sym || exit 1
- fi
+ test_ln_s_add hello $p ${p}sym || exit 1
done
)
find path* ! -type d -print | xargs git update-index --add
@@ -405,7 +386,7 @@ test_expect_success 'showing stage with git ls-files
--stage' '
'
test_expect_success 'validate git ls-files output for a known tree' '
- $expectfilter expected -\EOF
+ cat expected -\EOF
100644 f87290f8eb2cbbea7857214459a0739927eab154 0 path0
12 15a98433ae33114b085f3eb3bb03b832b3180a01 0 path0sym
100644 3feff949ed00a62d9f7af97c15cd8a30595e7ac7 0 path2/file2
@@ -423,14 +404,14 @@ test_expect_success 'writing tree out with git
write-tree' '
'
test_expect_success 'validate object ID for a known tree' '
- test $tree = $expectedtree
+ test $tree = 087704a96baf1c2d1c869a8b084481e121c88b5b
'
test_expect_success 'showing tree with git ls-tree' '
git ls-tree $tree current
'
-test_expect_success SYMLINKS 'git ls-tree output for a known tree' '
+test_expect_success 'git ls-tree output for a known tree' '
cat expected -\EOF
100644 blob f87290f8eb2cbbea7857214459a0739927eab154path0
12 blob 15a98433ae33114b085f3eb3bb03b832b3180a01path0sym
@@ -447,7 +428,7 @@ test_expect_success 'showing tree with git ls-tree -r' '
'
test_expect_success 'git ls-tree -r output for a known tree' '
- $expectfilter expected -\EOF
+ cat expected -\EOF
100644 blob f87290f8eb2cbbea7857214459a0739927eab154path0
12 blob 15a98433ae33114b085f3eb3bb03b832b3180a01path0sym
100644 blob 3feff949ed00a62d9f7af97c15cd8a30595e7ac7path2/file2
@@ -465,7 +446,7 @@ test_expect_success 'showing tree with git ls-tree -r -t' '
git ls-tree -r -t $tree current
'
-test_expect_success SYMLINKS 'git ls-tree -r output for a known tree' '
+test_expect_success 'git ls-tree -r output for a known tree' '
cat expected -\EOF
100644 blob f87290f8eb2cbbea7857214459a0739927eab154path0
12 blob 15a98433ae33114b085f3eb3bb03b832b3180a01path0sym
@@ -487,7 +468,7 @@ test_expect_success 'writing partial tree out with git
write-tree --prefix' '
'
test_expect_success 'validate object ID for a known tree' '
- test $ptree = $expectedptree1
+ test $ptree = 21ae8269cacbe57ae09138dcc3a2887f904d02b3
'
test_expect_success 'writing partial tree out with git write-tree --prefix' '
@@ -495,7 +476,7 @@ test_expect_success 'writing partial tree out with git
write-tree --prefix' '
'
test_expect_success 'validate object ID for a known tree' '
- test $ptree = $expectedptree2
+ test $ptree = 3c5e5399f3a333eddecce7a9b9465b63f65f51e2
'
test_expect_success 'put invalid objects into the index' '
@@ -529,7 +510,7 @@ test_expect_success 'git read-tree followed by write-tree
should be idempotent'
'
test_expect_success 'validate git diff-files
[PATCH v2 04/10] tests: use test_ln_s_add to remove SYMLINKS prerequisite (trivial cases)
There are many instances where the treatment of symbolic links in the object model and the algorithms are tested, but where it is not necessary to actually have a symbolic link in the worktree. Make adjustments to the tests and remove the SYMLINKS prerequisite when appropriate in trivial cases, where trivial means: - merely a replacement of 'ln -s a b git add b' by test_ln_s_add is needed; - a test for symbolic link on the file system can be split off (and remains protected by SYMLINKS); - existing code is equivalent to test_ln_s_add. Signed-off-by: Johannes Sixt j...@kdbg.org --- t/t1004-read-tree-m-u-wf.sh| 7 +++--- t/t2001-checkout-cache-clash.sh| 7 +++--- t/t2004-checkout-cache-temp.sh | 5 ++--- t/t2007-checkout-symlink.sh| 12 +-- t/t2021-checkout-overwrite.sh | 12 +++ t/t2200-add-update.sh | 5 ++--- t/t3010-ls-files-killed-modified.sh| 9 ++-- t/t3700-add.sh | 15 ++--- t/t3903-stash.sh | 39 -- t/t4008-diff-break-rewrite.sh | 12 +-- t/t4030-diff-textconv.sh | 8 +++ t/t4115-apply-symlink.sh | 10 - t/t4122-apply-symlink-inside.sh| 8 +++ t/t7001-mv.sh | 18 ++-- t/t7607-merge-overwrite.sh | 5 ++--- t/t8006-blame-textconv.sh | 14 +--- t/t8007-cat-file-textconv.sh | 10 - t/t9350-fast-export.sh | 5 ++--- t/t9500-gitweb-standalone-no-errors.sh | 15 + 19 files changed, 106 insertions(+), 110 deletions(-) diff --git a/t/t1004-read-tree-m-u-wf.sh b/t/t1004-read-tree-m-u-wf.sh index b3ae7d5..3e72aff 100755 --- a/t/t1004-read-tree-m-u-wf.sh +++ b/t/t1004-read-tree-m-u-wf.sh @@ -158,7 +158,7 @@ test_expect_success '3-way not overwriting local changes (their side)' ' ' -test_expect_success SYMLINKS 'funny symlink in work tree' ' +test_expect_success 'funny symlink in work tree' ' git reset --hard git checkout -b sym-b side-b @@ -170,15 +170,14 @@ test_expect_success SYMLINKS 'funny symlink in work tree' ' rm -fr a git checkout -b sym-a side-a mkdir -p a - ln -s ../b a/b - git add a/b + test_ln_s_add ../b a/b git commit -m we add a/b read_tree_u_must_succeed -m -u sym-a sym-a sym-b ' -test_expect_success SYMLINKS,SANITY 'funny symlink in work tree, un-unlink-able' ' +test_expect_success SANITY 'funny symlink in work tree, un-unlink-able' ' rm -fr a b git reset --hard diff --git a/t/t2001-checkout-cache-clash.sh b/t/t2001-checkout-cache-clash.sh index 98aa73e..1fc8e63 100755 --- a/t/t2001-checkout-cache-clash.sh +++ b/t/t2001-checkout-cache-clash.sh @@ -59,10 +59,9 @@ test_expect_success \ 'git read-tree -m $tree1 git checkout-index -f -a' test_debug 'show_files $tree1' -test_expect_success SYMLINKS \ -'git update-index --add a symlink.' \ -'ln -s path0 path1 - git update-index --add path1' +test_expect_success \ +'add a symlink' \ +'test_ln_s_add path0 path1' test_expect_success \ 'writing tree out with git write-tree' \ 'tree3=$(git write-tree)' diff --git a/t/t2004-checkout-cache-temp.sh b/t/t2004-checkout-cache-temp.sh index 0f4b289..f171a55 100755 --- a/t/t2004-checkout-cache-temp.sh +++ b/t/t2004-checkout-cache-temp.sh @@ -194,11 +194,10 @@ test_expect_success \ test $(cat ../$s1) = tree1asubdir/path5) )' -test_expect_success SYMLINKS \ +test_expect_success \ 'checkout --temp symlink' ' rm -f path* .merge_* out .git/index -ln -s b a -git update-index --add a +test_ln_s_add b a t4=$(git write-tree) rm -f .git/index git read-tree $t4 diff --git a/t/t2007-checkout-symlink.sh b/t/t2007-checkout-symlink.sh index e6f59f1..fc9aad5 100755 --- a/t/t2007-checkout-symlink.sh +++ b/t/t2007-checkout-symlink.sh @@ -6,7 +6,7 @@ test_description='git checkout to switch between branches with symlink-dir' . ./test-lib.sh -test_expect_success SYMLINKS setup ' +test_expect_success setup ' mkdir frotz echo hello frotz/filfre @@ -25,25 +25,25 @@ test_expect_success SYMLINKS setup ' git rm --cached frotz/filfre mv frotz xyzzy - ln -s xyzzy frotz - git add xyzzy/filfre frotz + test_ln_s_add xyzzy frotz + git add xyzzy/filfre test_tick git commit -m side moves frotz/ to xyzzy/ and adds frotz-xyzzy/ ' -test_expect_success SYMLINKS 'switch from symlink to dir' ' +test_expect_success 'switch from symlink to dir' ' git checkout master ' -test_expect_success SYMLINKS 'Remove temporary directories switch to master' ' +test_expect_success 'Remove temporary directories switch to master' ' rm -fr frotz xyzzy nitfol git checkout -f master '
[PATCH v2 00/22] git-remote-mediawiki: Follow perlcritic's recommandations
v2 of patch to follow perlcritic's recommandations ([1]) Changes with v1: - split first commit into 6 different commits - remove commit [17/18] about moving open() call - took every other comment into account [1]: http://thread.gmane.org/gmane.comp.version-control.git/226533 Célestin Matte (22): git-remote-mediawiki: Replace :utf8 by :encoding(UTF-8) git-remote-mediawiki: Use the Readonly module instead of the constant pragma git-remote-mediawiki: Always end a subroutine with a return git-remote-mediawiki: Move a variable declaration at the top of the code git-remote-mediawiki: Change syntax of map calls git-remote-mediawiki: Rewrite unclear line of instructions git-remote-mediawiki: Change style of some regular expressions git-remote-mediawiki: Add newline in the end of die() error messages git-remote-mediawiki: Change the name of a variable git-remote-mediawiki: Turn double-negated expressions into simple expressions git-remote-mediawiki: Remove unused variable $entry git-remote-mediawiki: Rename a variable ($last) which has the name of a keyword git-remote-mediawiki: Assign a variable as undef and make proper indentation git-remote-mediawiki: Check return value of open + remove import of unused open2 git-remote-mediawiki: Put long code into a subroutine git-remote-mediawiki: Modify strings for a better coding-style git-remote-mediawiki: Brace file handles for print for more clarity git-remote-mediawiki: Replace unless statements with negated if statements git-remote-mediawiki: Don't use quotes for empty strings git-remote-mediawiki: Put non-trivial numeric values in constants. git-remote-mediawiki: Fix a typo (mediwiki instead of mediawiki) git-remote-mediawiki: Clearly rewrite double dereference contrib/mw-to-git/git-remote-mediawiki.perl | 545 ++- 1 file changed, 293 insertions(+), 252 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/22] git-remote-mediawiki: Replace :utf8 by :encoding(UTF-8)
Follow perlcritic's InputOutput::RequireEncodingWithUTF8Layer policy
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 7b61e73..4893442 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -18,8 +18,8 @@ use DateTime::Format::ISO8601;
use warnings;
# By default, use UTF-8 to communicate with Git and the user
-binmode STDERR, :utf8;
-binmode STDOUT, :utf8;
+binmode STDERR, :encoding(UTF-8);
+binmode STDOUT, :encoding(UTF-8);
use URI::Escape;
use IPC::Open2;
@@ -588,7 +588,7 @@ sub literal_data_raw {
utf8::downgrade($content);
binmode STDOUT, :raw;
print STDOUT data , bytes::length($content), \n, $content;
- binmode STDOUT, :utf8;
+ binmode STDOUT, :encoding(UTF-8);
}
sub mw_capabilities {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/22] git-remote-mediawiki: Use the Readonly module instead of the constant pragma
Follow ValuesAndExpressions::ProhibitConstantPragma
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 4893442..e60793a 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -26,21 +26,21 @@ use IPC::Open2;
use Readonly;
# Mediawiki filenames can contain forward slashes. This variable decides by
which pattern they should be replaced
-use constant SLASH_REPLACEMENT = %2F;
+Readonly my $SLASH_REPLACEMENT = %2F;
# It's not always possible to delete pages (may require some
# privileges). Deleted pages are replaced with this content.
-use constant DELETED_CONTENT = [[Category:Deleted]]\n;
+Readonly my $DELETED_CONTENT = [[Category:Deleted]]\n;
# It's not possible to create empty pages. New empty files in Git are
# sent with this content instead.
-use constant EMPTY_CONTENT = !-- empty page --\n;
+Readonly my $EMPTY_CONTENT = !-- empty page --\n;
# used to reflect file creation or deletion in diff.
-use constant NULL_SHA1 = ;
+Readonly my $NULL_SHA1 = ;
# Used on Git's side to reflect empty edit messages on the wiki
-use constant EMPTY_MESSAGE = '*Empty MediaWiki Message*';
+Readonly my $EMPTY_MESSAGE = '*Empty MediaWiki Message*';
if (@ARGV != 2) {
exit_error_usage();
@@ -538,7 +538,7 @@ sub mediawiki_clean {
$string =~ s/\s+$//;
if ($string eq $page_created) {
# Creating empty pages is forbidden.
- $string = EMPTY_CONTENT;
+ $string = $EMPTY_CONTENT;
}
return $string.\n;
}
@@ -546,7 +546,7 @@ sub mediawiki_clean {
# Filter applied on MediaWiki data before adding them to Git
sub mediawiki_smudge {
my $string = shift;
- if ($string eq EMPTY_CONTENT) {
+ if ($string eq $EMPTY_CONTENT) {
$string = ;
}
# This \n is important. This is due to mediawiki's way to handle end of
files.
@@ -707,7 +707,7 @@ sub import_file_revision {
if (!$full_import $n == 1) {
print STDOUT from refs/mediawiki/$remotename/master^0\n;
}
- if ($content ne DELETED_CONTENT) {
+ if ($content ne $DELETED_CONTENT) {
print STDOUT M 644 inline .
fe_escape_path($title . .mw) . \n;
literal_data($content);
@@ -888,7 +888,7 @@ sub mw_import_revids {
my %commit;
$commit{author} = $rev-{user} || 'Anonymous';
- $commit{comment} = $rev-{comment} || EMPTY_MESSAGE;
+ $commit{comment} = $rev-{comment} || $EMPTY_MESSAGE;
$commit{title} = mediawiki_smudge_filename($page_title);
$commit{mw_revision} = $rev-{revid};
$commit{content} = mediawiki_smudge($rev-{'*'});
@@ -1006,14 +1006,14 @@ sub mw_push_file {
my $oldrevid = shift;
my $newrevid;
- if ($summary eq EMPTY_MESSAGE) {
+ if ($summary eq $EMPTY_MESSAGE) {
$summary = '';
}
my $new_sha1 = $diff_info_split[3];
my $old_sha1 = $diff_info_split[2];
- my $page_created = ($old_sha1 eq NULL_SHA1);
- my $page_deleted = ($new_sha1 eq NULL_SHA1);
+ my $page_created = ($old_sha1 eq $NULL_SHA1);
+ my $page_deleted = ($new_sha1 eq $NULL_SHA1);
$complete_file_name = mediawiki_clean_filename($complete_file_name);
my ($title, $extension) = $complete_file_name =~ /^(.*)\.([^\.]*)$/;
@@ -1032,7 +1032,7 @@ sub mw_push_file {
# special privileges. A common
# convention is to replace the page
# with this content instead:
- $file_content = DELETED_CONTENT;
+ $file_content = $DELETED_CONTENT;
} else {
$file_content = run_git(cat-file blob $new_sha1);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/22] git-remote-mediawiki: Change syntax of map calls
Put first parameter of map inside a block, for better readability.
Follow BuiltinFunctions::RequireBlockMap
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index dc8dd1f..5e348cb 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -372,7 +372,7 @@ sub get_all_mediafiles {
sub get_linked_mediafiles {
my $pages = shift;
- my @titles = map $_-{title}, values(%{$pages});
+ my @titles = map { $_-{title} } values(%{$pages});
# The query is split in small batches because of the MW API limit of
# the number of links to be returned (500 links max).
@@ -400,11 +400,13 @@ sub get_linked_mediafiles {
while (my ($id, $page) = each(%{$result-{query}-{pages}})) {
my @media_titles;
if (defined($page-{links})) {
- my @link_titles = map $_-{title},
@{$page-{links}};
+ my @link_titles
+ = map { $_-{title} } @{$page-{links}};
push(@media_titles, @link_titles);
}
if (defined($page-{images})) {
- my @image_titles = map $_-{title},
@{$page-{images}};
+ my @image_titles
+ = map { $_-{title} } @{$page-{images}};
push(@media_titles, @image_titles);
}
if (@media_titles) {
@@ -834,7 +836,7 @@ sub mw_import_ref_by_pages {
my ($n, @revisions) = fetch_mw_revisions(\@pages, $fetch_from);
@revisions = sort {$a-{revid} = $b-{revid}} @revisions;
- my @revision_ids = map $_-{revid}, @revisions;
+ my @revision_ids = map { $_-{revid} } @revisions;
return mw_import_revids($fetch_from, \@revision_ids, \%pages_hash);
}
@@ -1247,8 +1249,8 @@ sub get_allowed_file_extensions {
siprop = 'fileextensions'
};
my $result = $mediawiki-api($query);
- my @file_extensions= map
$_-{ext},@{$result-{query}-{fileextensions}};
- my %hashFile = map {$_ = 1}@file_extensions;
+ my @file_extensions = map { $_-{ext}}
@{$result-{query}-{fileextensions}};
+ my %hashFile = map { $_ = 1 } @file_extensions;
return %hashFile;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/22] git-remote-mediawiki: Rewrite unclear line of instructions
Subroutines' parameters should be affected to variable before doing anything
else
Besides, existing instruction affected a variable inside a if, which break
Git's coding style
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 5e348cb..a5c963b 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -1334,7 +1334,8 @@ sub get_mw_namespace_id {
}
sub get_mw_namespace_id_for_page {
- if (my ($namespace) = $_[0] =~ /^([^:]*):/) {
+ my $namespace = shift;
+ if ($namespace =~ /^([^:]*):/) {
return get_mw_namespace_id($namespace);
} else {
return;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/22] git-remote-mediawiki: Change the name of a variable
Local variable $url has the same name as a global variable. Changing the name
of the local variable prevents future possible misunderstanding.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git/git-remote-mediawiki.perl
index 4baad95..68fd129 100755
--- a/contrib/mw-to-git/git-remote-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -455,14 +455,14 @@ sub get_mw_mediafile_for_page_revision {
}
sub download_mw_mediafile {
- my $url = shift;
+ my $download_url = shift;
- my $response = $mediawiki-{ua}-get($url);
+ my $response = $mediawiki-{ua}-get($download_url);
if ($response-code == 200) {
return $response-decoded_content;
} else {
print STDERR Error downloading mediafile from :\n;
- print STDERR URL: $url\n;
+ print STDERR URL: $download_url\n;
print STDERR Server response: . $response-code . .
$response-message . \n;
exit 1;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
