* [PATCHv2 08/56] t6036: Add differently resolved modify/delete conflict in criss-cross test
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
In-Reply-To: <1313126429-17368-1-git-send-email-newren@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Changes since v1: Made wording change suggested by Junio.
t/t6036-recursive-corner-cases.sh | 83 +++++++++++++++++++++++++++++++++++++
1 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 319b6fa..90b50bb 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -231,4 +231,87 @@ test_expect_success 'git detects differently handled merges conflict' '
test $(git rev-parse :1:new_a) = $(git hash-object merged)
'
+#
+# criss-cross + modify/delete:
+#
+# B D
+# o---o
+# / \ / \
+# A o X ? F
+# \ / \ /
+# o---o
+# C E
+#
+# Commit A: file with contents 'A\n'
+# Commit B: file with contents 'B\n'
+# Commit C: file not present
+# Commit D: file with contents 'B\n'
+# Commit E: file not present
+#
+# Merging commits D & E should result in modify/delete conflict.
+
+test_expect_success 'setup criss-cross + modify/delete resolved differently' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ echo A >file &&
+ git add file &&
+ test_tick &&
+ git commit -m A &&
+
+ git branch B &&
+ git checkout -b C &&
+ git rm file &&
+ test_tick &&
+ git commit -m C &&
+
+ git checkout B &&
+ echo B >file &&
+ git add file &&
+ test_tick &&
+ git commit -m B &&
+
+ git checkout B^0 &&
+ test_must_fail git merge C &&
+ echo B >file &&
+ git add file &&
+ test_tick &&
+ git commit -m D &&
+ git tag D &&
+
+ git checkout C^0 &&
+ test_must_fail git merge B &&
+ git rm file &&
+ test_tick &&
+ git commit -m E &&
+ git tag E
+'
+
+test_expect_failure 'git detects conflict merging criss-cross+modify/delete' '
+ git checkout D^0 &&
+
+ test_must_fail git merge -s recursive E^0 &&
+
+ test 2 -eq $(git ls-files -s | wc -l) &&
+ test 2 -eq $(git ls-files -u | wc -l) &&
+
+ test $(git rev-parse :1:file) = $(git rev-parse master:file) &&
+ test $(git rev-parse :2:file) = $(git rev-parse B:file)
+'
+
+test_expect_failure 'git detects conflict merging criss-cross+modify/delete, reverse direction' '
+ git reset --hard &&
+ git checkout E^0 &&
+
+ test_must_fail git merge -s recursive D^0 &&
+
+ test 2 -eq $(git ls-files -s | wc -l) &&
+ test 2 -eq $(git ls-files -u | wc -l) &&
+
+ test $(git rev-parse :1:file) = $(git rev-parse master:file) &&
+ test $(git rev-parse :3:file) = $(git rev-parse B:file)
+'
+
test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related
* [PATCHv2 10/56] t6036: tests for criss-cross merges with various directory/file conflicts
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
In-Reply-To: <1313126429-17368-1-git-send-email-newren@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
---
Changes since v1: Lots of wording cleanups, made the tests more thorough.
t/t6036-recursive-corner-cases.sh | 159 +++++++++++++++++++++++++++++++++++++
1 files changed, 159 insertions(+), 0 deletions(-)
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 991c56d..acff84d 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -4,6 +4,12 @@ test_description='recursive merge corner cases involving criss-cross merges'
. ./test-lib.sh
+get_clean_checkout () {
+ git reset --hard &&
+ git clean -fdqx &&
+ git checkout "$1"
+}
+
#
# L1 L2
# o---o
@@ -397,4 +403,157 @@ test_expect_failure 'git detects conflict w/ criss-cross+contrived resolution' '
test $(git rev-parse :3:file) = $(git rev-parse E:file)
'
+#
+# criss-cross + d/f conflict via add/add:
+# Commit A: Neither file 'a' nor directory 'a/' exist.
+# Commit B: Introduce 'a'
+# Commit C: Introduce 'a/file'
+# Commit D: Merge B & C, keeping 'a' and deleting 'a/'
+#
+# Two different later cases:
+# Commit E1: Merge B & C, deleting 'a' but keeping 'a/file'
+# Commit E2: Merge B & C, deleting 'a' but keeping a slightly modified 'a/file'
+#
+# B D
+# o---o
+# / \ / \
+# A o X ? F
+# \ / \ /
+# o---o
+# C E1 or E2
+#
+# Merging D & E1 requires we first create a virtual merge base X from
+# merging A & B in memory. Now, if X could keep both 'a' and 'a/file' in
+# the index, then the merge of D & E1 could be resolved cleanly with both
+# 'a' and 'a/file' removed. Since git does not currently allow creating
+# such a tree, the best we can do is have X contain both 'a~<unique>' and
+# 'a/file' resulting in the merge of D and E1 having a rename/delete
+# conflict for 'a'. (Although this merge appears to be unsolvable with git
+# currently, git could do a lot better than it currently does with these
+# d/f conflicts, which is the purpose of this test.)
+#
+# Merge of D & E2 has similar issues for path 'a', but should always result
+# in a modify/delete conflict for path 'a/file'.
+#
+# We run each merge in both directions, to check for directional issues
+# with D/F conflict handling.
+#
+
+test_expect_success 'setup differently handled merges of directory/file conflict' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ >ignore-me &&
+ git add ignore-me &&
+ test_tick &&
+ git commit -m A &&
+ git tag A &&
+
+ git branch B &&
+ git checkout -b C &&
+ mkdir a &&
+ echo 10 >a/file &&
+ git add a/file &&
+ test_tick &&
+ git commit -m C &&
+
+ git checkout B &&
+ echo 5 >a &&
+ git add a &&
+ test_tick &&
+ git commit -m B &&
+
+ git checkout B^0 &&
+ test_must_fail git merge C &&
+ git clean -f &&
+ rm -rf a/ &&
+ echo 5 >a &&
+ git add a &&
+ test_tick &&
+ git commit -m D &&
+ git tag D &&
+
+ git checkout C^0 &&
+ test_must_fail git merge B &&
+ git clean -f &&
+ git rm --cached a &&
+ echo 10 >a/file &&
+ git add a/file &&
+ test_tick &&
+ git commit -m E1 &&
+ git tag E1 &&
+
+ git checkout C^0 &&
+ test_must_fail git merge B &&
+ git clean -f &&
+ git rm --cached a &&
+ printf "10\n11\n" >a/file &&
+ git add a/file &&
+ test_tick &&
+ git commit -m E2 &&
+ git tag E2
+'
+
+test_expect_failure 'merge of D & E1 fails but has appropriate contents' '
+ get_clean_checkout D^0 &&
+
+ test_must_fail git merge -s recursive E1^0 &&
+
+ test 2 -eq $(git ls-files -s | wc -l) &&
+ test 1 -eq $(git ls-files -u | wc -l) &&
+ test 0 -eq $(git ls-files -o | wc -l) &&
+
+ test $(git rev-parse :0:ignore-me) = $(git rev-parse A:ignore-me) &&
+ test $(git rev-parse :2:a) = $(git rev-parse B:a)
+'
+
+test_expect_failure 'merge of E1 & D fails but has appropriate contents' '
+ get_clean_checkout E1^0 &&
+
+ test_must_fail git merge -s recursive D^0 &&
+
+ test 2 -eq $(git ls-files -s | wc -l) &&
+ test 1 -eq $(git ls-files -u | wc -l) &&
+ test 0 -eq $(git ls-files -o | wc -l) &&
+
+ test $(git rev-parse :0:ignore-me) = $(git rev-parse A:ignore-me) &&
+ test $(git rev-parse :3:a) = $(git rev-parse B:a)
+'
+
+test_expect_success 'merge of D & E2 fails but has appropriate contents' '
+ get_clean_checkout D^0 &&
+
+ test_must_fail git merge -s recursive E2^0 &&
+
+ test 4 -eq $(git ls-files -s | wc -l) &&
+ test 3 -eq $(git ls-files -u | wc -l) &&
+ test 1 -eq $(git ls-files -o | wc -l) &&
+
+ test $(git rev-parse :2:a) = $(git rev-parse B:a) &&
+ test $(git rev-parse :3:a/file) = $(git rev-parse E2:a/file) &&
+ test $(git rev-parse :1:a/file) = $(git rev-parse C:a/file) &&
+ test $(git rev-parse :0:ignore-me) = $(git rev-parse A:ignore-me) &&
+
+ test -f a~HEAD
+'
+
+test_expect_failure 'merge of E2 & D fails but has appropriate contents' '
+ get_clean_checkout E2^0 &&
+
+ test_must_fail git merge -s recursive D^0 &&
+
+ test 4 -eq $(git ls-files -s | wc -l) &&
+ test 3 -eq $(git ls-files -u | wc -l) &&
+ test 1 -eq $(git ls-files -o | wc -l) &&
+
+ test $(git rev-parse :3:a) = $(git rev-parse B:a) &&
+ test $(git rev-parse :2:a/file) = $(git rev-parse E2:a/file) &&
+ test $(git rev-parse :1:a/file) = $(git rev-parse C:a/file)
+ test $(git rev-parse :0:ignore-me) = $(git rev-parse A:ignore-me) &&
+
+ test -f a~D^0
+'
+
test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related
* [PATCHv2 04/56] t6042: Add a testcase where undetected rename causes silent file deletion
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
In-Reply-To: <1313126429-17368-1-git-send-email-newren@gmail.com>
There are cases where history should merge cleanly, and which current git
does merge cleanly despite not detecting a rename; however the merge
currently nukes files that should not be removed.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
No changes since v1.
t/t6042-merge-rename-corner-cases.sh | 65 ++++++++++++++++++++++++++++++++++
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
index f338fb4..db5560c 100755
--- a/t/t6042-merge-rename-corner-cases.sh
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -133,4 +133,69 @@ test_expect_failure 'missed conflict if rename not detected' '
test_must_fail git merge -s recursive D^0
'
+# Tests for undetected rename/add-source causing a file to erroneously be
+# deleted (and for mishandled rename/rename(1to1) causing the same issue).
+#
+# This test uses a rename/rename(1to1)+add-source conflict (1to1 means the
+# same file is renamed on both sides to the same thing; it should trigger
+# the 1to2 logic, which it would do if the add-source didn't cause issues
+# for git's rename detection):
+# Commit A: new file: a
+# Commit B: rename a->b
+# Commit C: rename a->b, add unrelated a
+
+test_expect_success 'setup undetected rename/add-source causes data loss' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ printf "1\n2\n3\n4\n5\n" >a &&
+ git add a &&
+ git commit -m A &&
+ git tag A &&
+
+ git checkout -b B A &&
+ git mv a b &&
+ git commit -m B &&
+
+ git checkout -b C A &&
+ git mv a b &&
+ echo foobar >a &&
+ git add a &&
+ git commit -m C
+'
+
+test_expect_failure 'detect rename/add-source and preserve all data' '
+ git checkout B^0 &&
+
+ git merge -s recursive C^0 &&
+
+ test 2 -eq $(git ls-files -s | wc -l) &&
+ test 2 -eq $(git ls-files -u | wc -l) &&
+ test 0 -eq $(git ls-files -o | wc -l) &&
+
+ test -f a &&
+ test -f b &&
+
+ test $(git rev-parse HEAD:b) = $(git rev-parse A:a) &&
+ test $(git rev-parse HEAD:a) = $(git rev-parse C:a)
+'
+
+test_expect_failure 'detect rename/add-source and preserve all data, merge other way' '
+ git checkout C^0 &&
+
+ git merge -s recursive B^0 &&
+
+ test 2 -eq $(git ls-files -s | wc -l) &&
+ test 2 -eq $(git ls-files -u | wc -l) &&
+ test 0 -eq $(git ls-files -o | wc -l) &&
+
+ test -f a &&
+ test -f b &&
+
+ test $(git rev-parse HEAD:b) = $(git rev-parse A:a) &&
+ test $(git rev-parse HEAD:a) = $(git rev-parse C:a)
+'
+
test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related
* [PATCHv2 05/56] t6042: Add tests for content issues with modify/rename/directory conflicts
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
In-Reply-To: <1313126429-17368-1-git-send-email-newren@gmail.com>
Add testcases that cover a variety of merge issues with files being
renamed and modified on different sides of history, when there are
directories possibly conflicting with the rename location.
Case 1:
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a non-conflicting
way but is renamed to the location of the new directory.
Case 2:
[Same as case 1, but there is also a content conflict. In detail:]
On one side of history, a file is modified and a new directory is added.
On the other side of history, the file is modified in a conflicting way
and it is renamed to the location of the new directory.
Case 3:
[Similar to case 1, but the "conflicting" directory is the directory
where the file original resided. In detail:]
On one side of history, a file is modified. On the other side of history,
the file is modified in a non-conflicting way, but the directory it was
under is removed and the file is renamed to the location of the directory
it used to reside in (i.e. 'sub/file' gets renamed to 'sub'). This is
flagged as a directory/rename conflict, but should be able to be resolved
since the directory can be cleanly removed by the merge.
One branch renames a file and makes a file where the directory the renamed
file used to be in, and the other branch updates the file in
place. Merging them should resolve it cleanly as long as the content level
change on the branches do not overlap and rename is detected, or should
leave conflict without losing information.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
Changes since v1: New and improved commit message.
t/t6042-merge-rename-corner-cases.sh | 141 ++++++++++++++++++++++++++++++++++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
index db5560c..b465667 100755
--- a/t/t6042-merge-rename-corner-cases.sh
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -198,4 +198,145 @@ test_expect_failure 'detect rename/add-source and preserve all data, merge other
test $(git rev-parse HEAD:a) = $(git rev-parse C:a)
'
+test_expect_success 'setup content merge + rename/directory conflict' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ printf "1\n2\n3\n4\n5\n6\n" >file &&
+ git add file &&
+ test_tick &&
+ git commit -m base &&
+ git tag base &&
+
+ git checkout -b right &&
+ echo 7 >>file &&
+ mkdir newfile &&
+ echo junk >newfile/realfile &&
+ git add file newfile/realfile &&
+ test_tick &&
+ git commit -m right &&
+
+ git checkout -b left-conflict base &&
+ echo 8 >>file &&
+ git add file &&
+ git mv file newfile &&
+ test_tick &&
+ git commit -m left &&
+
+ git checkout -b left-clean base &&
+ echo 0 >newfile &&
+ cat file >>newfile &&
+ git add newfile &&
+ git rm file &&
+ test_tick &&
+ git commit -m left
+'
+
+test_expect_failure 'rename/directory conflict + clean content merge' '
+ git reset --hard &&
+ git reset --hard &&
+ git clean -fdqx &&
+
+ git checkout left-clean^0 &&
+
+ test_must_fail git merge -s recursive right^0 &&
+
+ test 2 -eq $(git ls-files -s | wc -l) &&
+ test 1 -eq $(git ls-files -u | wc -l) &&
+ test 1 -eq $(git ls-files -o | wc -l) &&
+
+ echo 0 >expect &&
+ git cat-file -p base:file >>expect &&
+ echo 7 >>expect &&
+ test_cmp expect newfile~HEAD &&
+
+ test $(git rev-parse :2:newfile) = $(git hash-object expect) &&
+
+ test -f newfile/realfile &&
+ test -f newfile~HEAD
+'
+
+test_expect_failure 'rename/directory conflict + content merge conflict' '
+ git reset --hard &&
+ git reset --hard &&
+ git clean -fdqx &&
+
+ git checkout left-conflict^0 &&
+
+ test_must_fail git merge -s recursive right^0 &&
+
+ test 4 -eq $(git ls-files -s | wc -l) &&
+ test 3 -eq $(git ls-files -u | wc -l) &&
+ test 1 -eq $(git ls-files -o | wc -l) &&
+
+ git cat-file -p left-conflict:newfile >left &&
+ git cat-file -p base:file >base &&
+ git cat-file -p right:file >right &&
+ test_must_fail git merge-file \
+ -L "HEAD:newfile" \
+ -L "" \
+ -L "right^0:file" \
+ left base right &&
+ test_cmp left newfile~HEAD &&
+
+ test $(git rev-parse :1:newfile) = $(git rev-parse base:file) &&
+ test $(git rev-parse :2:newfile) = $(git rev-parse left-conflict:newfile) &&
+ test $(git rev-parse :3:newfile) = $(git rev-parse right:file) &&
+
+ test -f newfile/realfile &&
+ test -f newfile~HEAD
+'
+
+test_expect_success 'setup content merge + rename/directory conflict w/ disappearing dir' '
+ git reset --hard &&
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ mkdir sub &&
+ printf "1\n2\n3\n4\n5\n6\n" >sub/file &&
+ git add sub/file &&
+ test_tick &&
+ git commit -m base &&
+ git tag base &&
+
+ git checkout -b right &&
+ echo 7 >>sub/file &&
+ git add sub/file &&
+ test_tick &&
+ git commit -m right &&
+
+ git checkout -b left base &&
+ echo 0 >newfile &&
+ cat sub/file >>newfile &&
+ git rm sub/file &&
+ mv newfile sub &&
+ git add sub &&
+ test_tick &&
+ git commit -m left
+'
+
+test_expect_success 'disappearing dir in rename/directory conflict handled' '
+ git reset --hard &&
+ git clean -fdqx &&
+
+ git checkout left^0 &&
+
+ git merge -s recursive right^0 &&
+
+ test 1 -eq $(git ls-files -s | wc -l) &&
+ test 0 -eq $(git ls-files -u | wc -l) &&
+ test 0 -eq $(git ls-files -o | wc -l) &&
+
+ echo 0 >expect &&
+ git cat-file -p base:sub/file >>expect &&
+ echo 7 >>expect &&
+ test_cmp expect sub &&
+
+ test -f sub
+'
+
test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related
* [PATCHv2 03/56] t6042: Add a pair of cases where undetected renames cause issues
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
In-Reply-To: <1313126429-17368-1-git-send-email-newren@gmail.com>
An undetected rename can cause a silent success where a conflict should
have been detected, or can cause an erroneous conflict state where the
merge should have been resolvable. Add testcases for both.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
No changes since v1.
t/t6042-merge-rename-corner-cases.sh | 61 ++++++++++++++++++++++++++++++++++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
index 276d7dd..f338fb4 100755
--- a/t/t6042-merge-rename-corner-cases.sh
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -72,4 +72,65 @@ test_expect_failure 'rename/modify/add-source conflict resolvable' '
test $(git rev-parse C:a) = $(git rev-parse a)
'
+test_expect_success 'setup resolvable conflict missed if rename missed' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ printf "1\n2\n3\n4\n5\n" >a &&
+ echo foo >b &&
+ git add a b &&
+ git commit -m A &&
+ git tag A &&
+
+ git checkout -b B A &&
+ git mv a c &&
+ echo "Completely different content" >a &&
+ git add a &&
+ git commit -m B &&
+
+ git checkout -b C A &&
+ echo 6 >>a &&
+ git add a &&
+ git commit -m C
+'
+
+test_expect_failure 'conflict caused if rename not detected' '
+ git checkout -q C^0 &&
+ git merge -s recursive B^0 &&
+
+ test 3 -eq $(git ls-files -s | wc -l) &&
+ test 0 -eq $(git ls-files -u | wc -l) &&
+ test 0 -eq $(git ls-files -o | wc -l) &&
+
+ test 6 -eq $(wc -l < c) &&
+ test $(git rev-parse HEAD:a) = $(git rev-parse B:a) &&
+ test $(git rev-parse HEAD:b) = $(git rev-parse A:b)
+'
+
+test_expect_success 'setup conflict resolved wrong if rename missed' '
+ git reset --hard &&
+ git clean -f &&
+
+ git checkout -b D A &&
+ echo 7 >>a &&
+ git add a &&
+ git mv a c &&
+ echo "Completely different content" >a &&
+ git add a &&
+ git commit -m D &&
+
+ git checkout -b E A &&
+ git rm a &&
+ echo "Completely different content" >>a &&
+ git add a &&
+ git commit -m E
+'
+
+test_expect_failure 'missed conflict if rename not detected' '
+ git checkout -q E^0 &&
+ test_must_fail git merge -s recursive D^0
+'
+
test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related
* [PATCHv2 02/56] t6042: Add failing testcase for rename/modify/add-source conflict
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
In-Reply-To: <1313126429-17368-1-git-send-email-newren@gmail.com>
If there is a cleanly resolvable rename/modify conflict AND there is a new
file introduced on the renamed side of the merge whose name happens to
match that of the source of the rename (but is otherwise unrelated to the
rename), then git fails to cleanly resolve the merge despite the fact that
the new file should not cause any problems.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
No changes since v1.
t/t6042-merge-rename-corner-cases.sh | 39 ++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
index 5054459..276d7dd 100755
--- a/t/t6042-merge-rename-corner-cases.sh
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -33,4 +33,43 @@ test_expect_failure "Does git preserve Gollum's precious artifact?" '
test -f ring
'
+# Testcase setup for rename/modify/add-source:
+# Commit A: new file: a
+# Commit B: modify a slightly
+# Commit C: rename a->b, add completely different a
+#
+# We should be able to merge B & C cleanly
+
+test_expect_success 'setup rename/modify/add-source conflict' '
+ git rm -rf . &&
+ git clean -fdqx &&
+ rm -rf .git &&
+ git init &&
+
+ printf "1\n2\n3\n4\n5\n6\n7\n" >a &&
+ git add a &&
+ git commit -m A &&
+ git tag A &&
+
+ git checkout -b B A &&
+ echo 8 >>a &&
+ git add a &&
+ git commit -m B &&
+
+ git checkout -b C A &&
+ git mv a b &&
+ echo something completely different >a &&
+ git add a &&
+ git commit -m C
+'
+
+test_expect_failure 'rename/modify/add-source conflict resolvable' '
+ git checkout B^0 &&
+
+ git merge -s recursive C^0 &&
+
+ test $(git rev-parse B:a) = $(git rev-parse b) &&
+ test $(git rev-parse C:a) = $(git rev-parse a)
+'
+
test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related
* [PATCHv2 01/56] t6042: Add a testcase where git deletes an untracked file
From: Elijah Newren @ 2011-08-12 5:19 UTC (permalink / raw)
To: gitster; +Cc: git, Jim Foucar, Elijah Newren
In-Reply-To: <1313126429-17368-1-git-send-email-newren@gmail.com>
Current git will nuke an untracked file during a rename/delete conflict if
(a) there is an untracked file whose name matches the source of a rename
and (b) the merge is done in a certain direction. Add a simple testcase
demonstrating this bug.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
No changes since v1.
t/t6036-recursive-corner-cases.sh | 2 +-
t/t6042-merge-rename-corner-cases.sh | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 1 deletions(-)
create mode 100755 t/t6042-merge-rename-corner-cases.sh
diff --git a/t/t6036-recursive-corner-cases.sh b/t/t6036-recursive-corner-cases.sh
index 871577d..319b6fa 100755
--- a/t/t6036-recursive-corner-cases.sh
+++ b/t/t6036-recursive-corner-cases.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='recursive merge corner cases'
+test_description='recursive merge corner cases involving criss-cross merges'
. ./test-lib.sh
diff --git a/t/t6042-merge-rename-corner-cases.sh b/t/t6042-merge-rename-corner-cases.sh
new file mode 100755
index 0000000..5054459
--- /dev/null
+++ b/t/t6042-merge-rename-corner-cases.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+test_description="recursive merge corner cases w/ renames but not criss-crosses"
+# t6036 has corner cases that involve both criss-cross merges and renames
+
+. ./test-lib.sh
+
+test_expect_success 'setup rename/delete + untracked file' '
+ echo "A pretty inscription" >ring &&
+ git add ring &&
+ test_tick &&
+ git commit -m beginning &&
+
+ git branch people &&
+ git checkout -b rename-the-ring &&
+ git mv ring one-ring-to-rule-them-all &&
+ test_tick &&
+ git commit -m fullname &&
+
+ git checkout people &&
+ git rm ring &&
+ echo gollum >owner &&
+ git add owner &&
+ test_tick &&
+ git commit -m track-people-instead-of-objects &&
+ echo "Myyy PRECIOUSSS" >ring
+'
+
+test_expect_failure "Does git preserve Gollum's precious artifact?" '
+ test_must_fail git merge -s recursive rename-the-ring &&
+
+ # Make sure git did not delete an untracked file
+ test -f ring
+'
+
+test_done
--
1.7.6.100.gac5c1
^ permalink raw reply related
* Re: [PATCH 0/6] Towards a generalized sequencer
From: Ramkumar Ramachandra @ 2011-08-12 3:17 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King, Johannes Schindelin
In-Reply-To: <20110812023323.GA672@elie.gateway.2wire.net>
Hi,
[+CC: Johannes Schindelin]
Jonathan Nieder writes:
> Isn't it still the same built-in cherry-pick code, originally by Dscho
> and improved over time by others? The filename is irrelevant.
True, but we can't have "This implements the builtins revert and
cherry-pick." in sequencer.c, no?
> If you want to add your and Christian's names to reflect
> multiple-cherry-pick and the restructuring, I guess that would be ok.
> Better yet, if you want to remove Dscho's name to encourage people to
> look at the commit log and get a richer story, just ask Dscho.
I thought about this a bit. I'm completely against the former option
-- I merely meant it as a "I'm confused; help!" rather than a
suggestion; adding contributors' names to the list is a bad idea. I
looked at some copyright notices in other files and re-evaluated: it's
a cute historical note to have. Unless Johannes wants to remove it
now, I'd like to put the following in sequencer.c:
/*
* Used to implement the builtins revert and cherry-pick.
*
* Copyright (c) 2007 Johannes E. Schindelin
*
* Based on git-revert.sh, which is
*
* Copyright (c) 2005 Linus Torvalds
* Copyright (c) 2005 Junio C Hamano
*/
Sorry about the confusion. Feel free to suggest a better "title line".
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 0/6] Towards a generalized sequencer
From: Jonathan Nieder @ 2011-08-12 2:33 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <CALkWK0nXAU+jFwyzmYC6XuPGy8Cdmbpis0Nvb-M+tQSNk_PXiQ@mail.gmail.com>
Ramkumar Ramachandra wrote:
> 2. Should I move it to sequencer.c and and modify it accordingly?
> It'll read Copyright (C) 2011 <Me>, based on builtin/revert.c which is
> Copyright Dscho, which in turn is based on git-revert.sh
[...]
Isn't it still the same built-in cherry-pick code, originally by Dscho
and improved over time by others? The filename is irrelevant.
If you want to add your and Christian's names to reflect
multiple-cherry-pick and the restructuring, I guess that would be ok.
Better yet, if you want to remove Dscho's name to encourage people to
look at the commit log and get a richer story, just ask Dscho.
Asking would (1) show that you value his contribution and respect his
wishes and (2) allow him to say, "no, I really prefer to keep my name
there for such-and-such copyright-related reason". Of course these
are only my own thoughts. Maybe I'm too picky.
^ permalink raw reply
* Re: [PATCH 6/6] sequencer: Remove sequencer state after final commit
From: Ramkumar Ramachandra @ 2011-08-12 2:19 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110811201755.GJ2277@elie.gateway.2wire.net>
Hi again,
Jonathan Nieder writes:
> Dear sequencer, I'm commiting!
Interesting. I was worried that sequencer_count_todo() might be a bit
of an overkill. I can't find any other usecase for counting the
number of commits in the instruction sheet right now, and it's
unlikely that I'll find any callers for it in the future either. I
suppose we can save time by just counting until we figure out that
more than one commit exists -- there's no need to find the exact
number.
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 0/6] Towards a generalized sequencer
From: Ramkumar Ramachandra @ 2011-08-12 2:14 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110811190312.GD2277@elie.gateway.2wire.net>
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>> Note: I didn't know what to do with the license header in the fifth
>> patch. I just assumed that it was some historical cruft and removed
>> it.
>
> Please don't. Technically it's allowed by the license if I understand
> correctly (since the copyright notices are not accompanied by a
> disclaimer of warranty) but it's almost always the wrong thing to do
> to remove a copyright notice without the author's permission.
Um, ok. I still don't know what to do:
1. Should I leave it in builtin/revert.c? There are only a few tiny
functions left there.
2. Should I move it to sequencer.c and and modify it accordingly?
It'll read Copyright (C) 2011 <Me>, based on builtin/revert.c which is
Copyright Dscho, which in turn is based on git-revert.sh Copyright
Linus and Junio? Isn't this information redundant? Can't `log` and
`blame -M -C` do a much better job?
Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 2/6] revert: Free memory after get_message call
From: Ramkumar Ramachandra @ 2011-08-12 2:07 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110811192403.GF2277@elie.gateway.2wire.net>
Hi Jonathan,
Jonathan Nieder writes:
> I don't see how this could work. Since there an xmalloc() in each
> loop iteration, I would have expected the free() to be in the loop
> body, too.
Oops, fixed. Thanks.
-- Ram
^ permalink raw reply
* Re: [PATCH 5/6] sequencer: Expose API to cherry-picking machinery
From: Junio C Hamano @ 2011-08-11 23:47 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <20110811215650.GA13839@elie.gateway.2wire.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Another thought. I wonder if it's possible to leave
> sequencer_parse_args() private to builtin/revert.c, making the split
> a little more logical:
>
> - the builtin takes responsibility for its commandline interface
> - the library takes over once the builtin has figured out what the
> user wanted.
That's a very natural separation of tasks.
^ permalink raw reply
* Re: [PATCH v3 2/2] Reduce parse-options.o dependencies
From: Junio C Hamano @ 2011-08-11 23:35 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Dmitry Ivankov, git, David Barr, Stephen Boyd
In-Reply-To: <20110811110441.GD5012@elie.gateway.2wire.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> diff --git a/parse-options-cb.c b/parse-options-cb.c
>> new file mode 100644
>> index 0000000..c248f66
>> --- /dev/null
>> +++ b/parse-options-cb.c
>> @@ -0,0 +1,125 @@
>> +#include "git-compat-util.h"
>> +#include "parse-options.h"
>> +#include "cache.h"
>
> Style: Files in git tend to use only one of "git-compat-util.h",
> "cache.h", or "builtin.h" and put it at the top. So in this case, it
> should probably use just "cache.h".
This needs a bit of clarification.
The compatibility rule actually is to have git-compat-util.h at the very
beginning. As cache.h is a very widely used header almost everybody that
needs to access the internals include, it includes git-compat-util.h as
its first thing to include.
So if this is an old file that existed before git-compat-util.h, then it
is perfectly fine to start it with
#include "cache.h"
#include "parse-options.h"
Otherwise the three-line include above is also just fine.
^ permalink raw reply
* Re: [PATCH v2 2/2] Move git-dir for submodules
From: Junio C Hamano @ 2011-08-11 23:34 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: git, jens.lehmann, hvoigt
In-Reply-To: <1312831022-12868-3-git-send-email-iveqy@iveqy.com>
Fredrik Gustafsson <iveqy@iveqy.com> writes:
> Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of
> the superproject. This is a step towards being able to delete submodule
> directories without loosing the information from their .git directory
> as that is now stored outside the submodules work tree.
>
> This is done relying on the already existent .git-file functionality.
> When adding or updating a submodule whose git directory is found under
> $GIT_DIR/modules/[name_of_submodule], don't clone it again but simply
> point the .git-file to it and remove the now stale index file from it.
And the index is populated to match the correct commit how?
> Tests that rely on .git being a directory have been fixed.
Thanks.
How would this interact with submodule repositories that are already
initialized in-place?
^ permalink raw reply
* Re: [PATCH v2 1/2] rev-parse: add option --is-well-formed-git-dir [path]
From: Junio C Hamano @ 2011-08-11 23:34 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: git, jens.lehmann, hvoigt
In-Reply-To: <1312831022-12868-2-git-send-email-iveqy@iveqy.com>
Fredrik Gustafsson <iveqy@iveqy.com> writes:
> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
> index 4c19f84..82342b3 100644
> --- a/builtin/rev-parse.c
> +++ b/builtin/rev-parse.c
> @@ -455,6 +455,14 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
> unsigned char sha1[20];
> const char *name = NULL;
>
> + if (argc > 2 && !strcmp(argv[1], "--is-well-formed-git-dir")) {
> + const char *gitdir = resolve_gitdir(argv[2]);
> + if(!gitdir)
(style) SP immediately after "if".
> + die("not a gitdir");
die("not a gitdir '%s'", argv[2]) perhaps?
> + puts(gitdir);
> + return 0;
> + }
> +
> if (argc > 1 && !strcmp("--parseopt", argv[1]))
> return cmd_parseopt(argc - 1, argv + 1, prefix);
When adding a new element to existing list of other similar things, I
would prefer to see it added at the end (in this case, just before "-h",
which is kind of special), unless there is a good justification not to
(e.g. the list is sorted alphabetically).
> diff --git a/setup.c b/setup.c
> index 5ea5502..15bc305 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -808,3 +808,10 @@ const char *setup_git_directory(void)
> {
> return setup_git_directory_gently(NULL);
> }
> +
> +const char *resolve_gitdir(const char *suspect)
> +{
> + if(is_git_directory(suspect))
(style) SP immediately after "if".
^ permalink raw reply
* [FFT/PATCH 12/11] object.c: make object hash implementation more opaque
From: Junio C Hamano @ 2011-08-11 23:33 UTC (permalink / raw)
To: git
In-Reply-To: <1313085196-13249-1-git-send-email-gitster@pobox.com>
There are only a handful of callers that want to enumerate all the objects
known to the process. Unfortunately they at least know that the object
hash can be iterated over with an integer index.
Introduce an opaque "struct object_cursor" type to hide the implementation
detail, so that later we may be able to switch to an implementation that
is not a based on a flat and sparse array that is used as a hash table.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is not necessary for the purpose of the earlier "cuckoo" update,
as that still is an implementation based on a single flat sparse array,
but I am throwing it out as a food-for-thought.
- The function "object_cursor_max()" returns obj_hash_size, but it only
is used by fsck to give an overestimate of the number of objects to
check. We could change it to return nr_obj to give a more precise
number, but I kept the behaviour bug-for-bug compatible for now.
- Later if we need to libify the in-core object store, we would wrap
obj_hash, nr_obj and obj_hash_size into a single "struct obj_ctx"
(the context of a series of git operations that access the object
store), and have a pointer to it in the "struct object_cursor".
get_object_cursor() API function may get a new variant that takes a
pointer to "struct obj_ctx" to switch between contexts, etc.
This patch is designed to apply before all the others, outside the main
series. If this "more opaque" approach is going in a desirable
direction, the "cuckoo" series should be rebased on top of this.
builtin/fsck.c | 17 ++++++++---------
builtin/index-pack.c | 10 ++++++----
builtin/name-rev.c | 12 +++++-------
object.c | 34 ++++++++++++++++++++++++++++++----
object.h | 7 +++++--
5 files changed, 54 insertions(+), 26 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 5ae0366..a71b36d 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -266,22 +266,21 @@ static void check_object(struct object *obj)
static void check_connectivity(void)
{
- int i, max;
+ struct object_cursor *objects;
+ struct object *obj;
/* Traverse the pending reachable objects */
traverse_reachable();
/* Look up all the requirements, warn about missing objects.. */
- max = get_max_object_index();
+ objects = get_object_cursor();
if (verbose)
- fprintf(stderr, "Checking connectivity (%d objects)\n", max);
-
- for (i = 0; i < max; i++) {
- struct object *obj = get_indexed_object(i);
+ fprintf(stderr, "Checking connectivity (%d objects)\n",
+ object_cursor_max(objects));
- if (obj)
- check_object(obj);
- }
+ while ((obj = get_next_object(objects)) != NULL)
+ check_object(obj);
+ free_object_cursor(objects);
}
static int fsck_sha1(const unsigned char *sha1)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index e40451f..ca172d5 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -104,11 +104,13 @@ static void check_object(struct object *obj)
static void check_objects(void)
{
- unsigned i, max;
+ struct object_cursor *objects;
+ struct object *obj;
- max = get_max_object_index();
- for (i = 0; i < max; i++)
- check_object(get_indexed_object(i));
+ objects = get_object_cursor();
+ while ((obj = get_next_object(objects)) != NULL)
+ check_object(obj);
+ free_object_cursor(objects);
}
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 31f5c1c..ec6b952 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
@@ -284,16 +284,14 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
name_rev_line(p, &data);
}
} else if (all) {
- int i, max;
+ struct object_cursor *objects;
+ struct object *obj;
- max = get_max_object_index();
- for (i = 0; i < max; i++) {
- struct object *obj = get_indexed_object(i);
- if (!obj)
- continue;
+ objects = get_object_cursor();
+ while ((obj = get_next_object(objects)) != NULL)
show_name(obj, NULL,
always, allow_undefined, data.name_only);
- }
+ free_object_cursor(objects);
} else {
int i;
for (i = 0; i < revs.nr; i++)
diff --git a/object.c b/object.c
index 31976b5..986d243 100644
--- a/object.c
+++ b/object.c
@@ -8,14 +8,40 @@
static struct object **obj_hash;
static int nr_objs, obj_hash_size;
-unsigned int get_max_object_index(void)
+struct object_cursor {
+ int cursor_at;
+};
+
+struct object_cursor *get_object_cursor(void)
{
- return obj_hash_size;
+ struct object_cursor *objects;
+ objects = xmalloc(sizeof(*objects));
+ objects->cursor_at = 0;
+ return objects;
+}
+
+int object_cursor_max(struct object_cursor *objects)
+{
+ return obj_hash_size; /* nr_objs is more precise, though */
+}
+
+struct object *get_next_object(struct object_cursor *objects)
+{
+ int i = objects->cursor_at;
+ while (i < obj_hash_size) {
+ struct object *obj = obj_hash[i++];
+ if (!obj)
+ continue;
+ objects->cursor_at = i;
+ return obj;
+ }
+ objects->cursor_at = i;
+ return NULL;
}
-struct object *get_indexed_object(unsigned int idx)
+void free_object_cursor(struct object_cursor *objects)
{
- return obj_hash[idx];
+ free(objects);
}
static const char *object_type_strings[] = {
diff --git a/object.h b/object.h
index b6618d9..fdd14a1 100644
--- a/object.h
+++ b/object.h
@@ -35,8 +35,11 @@ struct object {
extern const char *typename(unsigned int type);
extern int type_from_string(const char *str);
-extern unsigned int get_max_object_index(void);
-extern struct object *get_indexed_object(unsigned int);
+struct object_cursor; /* opaque */
+extern struct object_cursor *get_object_cursor(void);
+extern int object_cursor_max(struct object_cursor *);
+extern struct object *get_next_object(struct object_cursor *);
+extern void free_object_cursor(struct object_cursor *);
/*
* This can be used to see if we have heard of the object before, but
^ permalink raw reply related
* Re: Suggestions to make git easier to understand
From: Jonathan Nieder @ 2011-08-11 23:08 UTC (permalink / raw)
To: Junio C Hamano
Cc: Philippe Vaucher, git, Rafael Magana,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vmxffpo8e.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I do not think "ls-files --contents" makes things any better, though.
> Until a new user encounters a conflicted state, it might look like that
> the primary point of "ls-files -s" is to show the object names, but it
> also is important that it shows the stage numbers.
Yes, sloppy of me. I should have said "the intent of these
suggestions seems reasonable, and I believe that with minimal tweaking
they would all lead to good things".
In the case of "ls-files -s", I suspect what would be most useful is
a new porcelain "git ls --merge", building on Duy's work[*].
[*] http://thread.gmane.org/gmane.comp.version-control.git/166405/focus=166415
^ permalink raw reply
* Re: Suggestions to make git easier to understand
From: Junio C Hamano @ 2011-08-11 22:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Philippe Vaucher, git, Rafael Magana
In-Reply-To: <20110811221627.GA32005@elie.gateway.2wire.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> Maybe
>> --cached could have an alias like --index-only for things to be more
>> intuitive as well.
>>
>> `git rm --index-only somefile` is more understandable than `git rm
>> --cached somefile` imho.
>>
>> Also, in ls-files, --stage could maybe use an alias like --contents
>> for it to be more self-explanatory.
>
> These suggestions also seem sane.
The --index-only synonym was throwed around in a handful of discussions in
the past. It probably would not hurt, I would say.
I do not think "ls-files --contents" makes things any better, though.
Until a new user encounters a conflicted state, it might look like that
the primary point of "ls-files -s" is to show the object names, but it
also is important that it shows the stage numbers.
^ permalink raw reply
* What's cooking in git.git (Aug 2011, #03; Thu, 11)
From: Junio C Hamano @ 2011-08-11 22:34 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
I am envisioning that we would declare feature freeze after most of the
topics that are in 'next' as of today graduate to 'master' for the next
release, and keep the remainder cooking for the cycle after that. Hopefully
that would happen around 24th.
--------------------------------------------------
[New Topics]
* di/fast-import-ident (2011-08-11) 5 commits
- fsck: improve committer/author check
- fsck: add a few committer name tests
- fast-import: check committer name more strictly
- fast-import: don't fail on omitted committer name
- fast-import: add input format tests
* fg/submodule-ff-check-before-push (2011-08-09) 1 commit
- push: Don't push a repository with unpushed submodules
* hv/submodule-update-none (2011-08-11) 2 commits
- add update 'none' flag to disable update of submodule by default
- submodule: move update configuration variable further up
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
* js/i18n-scripts (2011-08-08) 5 commits
- submodule: take advantage of gettextln and eval_gettextln.
- stash: take advantage of eval_gettextln
- pull: take advantage of eval_gettextln
- git-am: take advantage of gettextln and eval_gettextln.
- gettext: add gettextln, eval_gettextln to encode common idiom
--------------------------------------------------
[Graduated to "master"]
* cb/partial-commit-relative-pathspec (2011-08-02) 1 commit
(merged to 'next' on 2011-08-03 at 6918f69)
+ commit: allow partial commits with relative paths
Ideally the pathspec-prefix helper should be renamed to something more
sensible, but we could live with it for now.
* ef/ipv4-connect-error-report (2011-08-01) 2 commits
(merged to 'next' on 2011-08-03 at ea4842b)
+ connect: only log if all attempts failed (ipv4)
+ Merge branch 'maint' into ef/ipv4-connect-error-report
* jk/fast-export-quote-path (2011-08-05) 1 commit
(merged to 'next' on 2011-08-05 at a80e5f5)
+ fast-export: quote paths in output
* rc/maint-http-wrong-free (2011-08-03) 2 commits
(merged to 'next' on 2011-08-05 at cea08ed)
+ Makefile: some changes for http-related flag documentation
+ http.c: fix an invalid free()
* rs/grep-function-context (2011-08-01) 2 commits
(merged to 'next' on 2011-08-05 at 8d63a8c)
+ grep: long context options
+ grep: add option to show whole function as context
--------------------------------------------------
[Stalled]
* jc/merge-reword (2011-05-25) 2 commits
- merge: mark the final "Merge made by..." message for l10n
- merge: reword the final message
Probably the topmost commit should be dropped.
* nk/branch-v-abbrev (2011-07-01) 1 commit
- branch -v: honor core.abbrev
Perhaps needs an updated commit log message?
* di/fast-import-doc (2011-07-13) 2 commits
- doc/fast-import: document feature import-marks-if-exists
- doc/fast-import: clarify notemodify command
Comments from fast-import folks?
* jh/receive-count-limit (2011-05-23) 10 commits
- receive-pack: Allow server to refuse pushes with too many objects
- pack-objects: Estimate pack size; abort early if pack size limit is exceeded
- send-pack/receive-pack: Allow server to refuse pushing too large packs
- pack-objects: Allow --max-pack-size to be used together with --stdout
- send-pack/receive-pack: Allow server to refuse pushes with too many commits
- pack-objects: Teach new option --max-commit-count, limiting #commits in pack
- receive-pack: Prepare for addition of the new 'limit-*' family of capabilities
- Tighten rules for matching server capabilities in server_supports()
- send-pack: Attempt to retrieve remote status even if pack-objects fails
- Update technical docs to reflect side-band-64k capability in receive-pack
Would need another round to separate per-pack and per-session limits.
* jm/mergetool-pathspec (2011-06-22) 2 commits
- mergetool: Don't assume paths are unmerged
- mergetool: Add tests for filename with whitespace
I think this is a good idea, but it probably needs a re-roll.
Cf. $gmane/176254, 176255, 166256
* jk/generation-numbers (2011-07-14) 7 commits
- limit "contains" traversals based on commit generation
- check commit generation cache validity against grafts
- pretty: support %G to show the generation number of a commit
- commit: add commit_generation function
- add metadata-cache infrastructure
- decorate: allow storing values instead of pointers
- Merge branch 'jk/tag-contains-ab' (early part) into HEAD
The initial "tag --contains" de-pessimization without need for generation
numbers is already in; backburnered.
* en/merge-recursive (2011-08-04) 49 commits
- t3030: fix accidental success in symlink rename
- merge-recursive: Fix working copy handling for rename/rename/add/add
- merge-recursive: add handling for rename/rename/add-dest/add-dest
- merge-recursive: Have conflict_rename_delete reuse modify/delete code
- merge-recursive: Make modify/delete handling code reusable
- merge-recursive: Consider modifications in rename/rename(2to1) conflicts
- merge-recursive: Create function for merging with branchname:file markers
- merge-recursive: Record more data needed for merging with dual renames
- merge-recursive: Defer rename/rename(2to1) handling until process_entry
- merge-recursive: Small cleanups for conflict_rename_rename_1to2
- merge-recursive: Fix rename/rename(1to2) resolution for virtual merge base
- merge-recursive: Introduce a merge_file convenience function
- merge-recursive: Fix modify/delete resolution in the recursive case
- merge-recursive: Provide more info in conflict markers with file renames
- merge-recursive: Cleanup and consolidation of rename_conflict_info
- merge-recursive: Consolidate process_entry() and process_df_entry()
- merge-recursive: Improve handling of rename target vs. directory addition
- merge-recursive: Add comments about handling rename/add-source cases
- merge-recursive: Make dead code for rename/rename(2to1) conflicts undead
- merge-recursive: Fix deletion of untracked file in rename/delete conflicts
- merge-recursive: When we detect we can skip an update, actually skip it
- merge-recursive: Split update_stages_and_entry; only update stages at end
- merge-recursive: Consolidate different update_stages functions
- merge-recursive: Allow make_room_for_path() to remove D/F entries
- merge-recursive: Split was_tracked() out of would_lose_untracked()
- merge-recursive: Save D/F conflict filenames instead of unlinking them
- merge-recursive: Fix code checking for D/F conflicts still being present
- merge-recursive: Fix sorting order and directory change assumptions
- merge-recursive: Fix recursive case with D/F conflict via add/add conflict
- merge-recursive: Avoid working directory changes during recursive case
- merge-recursive: Remember to free generated unique path names
- merge-recursive: Mark some diff_filespec struct arguments const
- merge-recursive: Correct a comment
- merge-recursive: Make BUG message more legible by adding a newline
- t6022: Add testcase for merging a renamed file with a simple change
- t6022: New tests checking for unnecessary updates of files
- t6022: Remove unnecessary untracked files to make test cleaner
- t6036: criss-cross + rename/rename(1to2)/add-source + modify/modify
- t6036: criss-cross w/ rename/rename(1to2)/modify+rename/rename(2to1)/modify
- t6036: tests for criss-cross merges with various directory/file conflicts
- t6036: criss-cross with weird content can fool git into clean merge
- t6036: Add differently resolved modify/delete conflict in criss-cross test
- t6042: Ensure rename/rename conflicts leave index and workdir in sane state
- t6042: Add failing testcases for rename/rename/add-{source,dest} conflicts
- t6042: Add tests for content issues with modify/rename/directory conflicts
- t6042: Add a testcase where undetected rename causes silent file deletion
- t6042: Add a pair of cases where undetected renames cause issues
- t6042: Add failing testcase for rename/modify/add-source conflict
- t6042: Add a testcase where git deletes an untracked file
Re-roll being worked on.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
* po/cygwin-backslash (2011-08-05) 2 commits
- On Cygwin support both UNIX and DOS style path-names
- git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
I think a further refactoring (no, not my suggestion) was offered?
--------------------------------------------------
[Cooking]
* cb/maint-ls-files-error-report (2011-08-11) 1 commit
- ls-files: fix pathspec display on error
Will merge to "next".
* ac/describe-dirty-refresh (2011-08-11) 1 commit
- describe: Refresh the index when run with --dirty
Will merge to "next".
* jc/maint-combined-diff-work-tree (2011-08-04) 1 commit
(merged to 'next' on 2011-08-05 at 976a4d4)
+ diff -c/--cc: do not mistake "resolved as deletion" as "use working tree"
Will merge to "master" after cooking for a bit more.
* js/sh-style (2011-08-05) 2 commits
(merged to 'next' on 2011-08-11 at 4a4c22c)
+ filter-branch.sh: de-dent usage string
+ misc-sh: fix up whitespace in some other .sh files.
* ma/am-exclude (2011-08-09) 2 commits
(merged to 'next' on 2011-08-11 at cf0ba4d)
+ am: Document new --exclude=<path> option
(merged to 'next' on 2011-08-05 at 658e57c)
+ am: pass exclude down to apply
Will merge to "master" after cooking for a bit more.
* db/am-skip-blank-at-the-beginning (2011-08-11) 1 commit
(merged to 'next' on 2011-08-11 at 3637843)
+ am: ignore leading whitespace before patch
Will merge to "master" after cooking for a bit more.
* jc/maint-smart-http-race-upload-pack (2011-08-08) 1 commit
(merged to 'next' on 2011-08-11 at 3f24b64)
+ helping smart-http/stateless-rpc fetch race
* jn/maint-test-return (2011-08-11) 3 commits
- t3900: do not reference numbered arguments from the test script
- test: cope better with use of return for errors
- test: simplify return value of test_run_
Will merge to "next".
* rt/zlib-smaller-window (2011-08-11) 2 commits
- test: consolidate definition of $LF
- Tolerate zlib deflation with window size < 32Kb
Will merge to "next".
* fg/submodule-git-file-git-dir (2011-08-08) 3 commits
- Move git-dir for submodules
- fixup! rev-parse: add option --is-well-formed-git-dir
- rev-parse: add option --is-well-formed-git-dir <path>
* js/bisect-no-checkout (2011-08-09) 11 commits
(merged to 'next' on 2011-08-11 at 6c94a45)
+ bisect: add support for bisecting bare repositories
+ bisect: further style nitpicks
+ bisect: replace "; then" with "\n<tab>*then"
+ bisect: cleanup whitespace errors in git-bisect.sh.
+ bisect: add documentation for --no-checkout option.
+ bisect: add tests for the --no-checkout option.
+ bisect: introduce --no-checkout support into porcelain.
+ bisect: introduce support for --no-checkout option.
+ bisect: add tests to document expected behaviour in presence of broken trees.
+ bisect: use && to connect statements that are deferred with eval.
+ bisect: move argument parsing before state modification.
* cb/maint-exec-error-report (2011-08-01) 2 commits
(merged to 'next' on 2011-08-05 at 2764424)
+ notice error exit from pager
+ error_routine: use parent's stderr if exec fails
Will merge to "master" after cooking for a bit more.
* cb/maint-quiet-push (2011-08-08) 2 commits
(merged to 'next' on 2011-08-08 at 917d73b)
+ receive-pack: do not overstep command line argument array
(merged to 'next' on 2011-08-01 at 87df938)
+ propagate --quiet to send-pack/receive-pack
Will merge to "master" after cooking for a bit more.
* jk/add-i-hunk-filter (2011-07-27) 5 commits
(merged to 'next' on 2011-08-11 at 8ff9a56)
+ add--interactive: add option to autosplit hunks
+ add--interactive: allow negatation of hunk filters
+ add--interactive: allow hunk filtering on command line
+ add--interactive: factor out regex error handling
+ add--interactive: refactor patch mode argument processing
* mh/check-attr-listing (2011-08-04) 23 commits
(merged to 'next' on 2011-08-11 at f73ad50)
+ Rename git_checkattr() to git_check_attr()
+ git-check-attr: Fix command-line handling to match docs
+ git-check-attr: Drive two tests using the same raw data
+ git-check-attr: Add an --all option to show all attributes
+ git-check-attr: Error out if no pathnames are specified
+ git-check-attr: Process command-line args more systematically
+ git-check-attr: Handle each error separately
+ git-check-attr: Extract a function error_with_usage()
+ git-check-attr: Introduce a new variable
+ git-check-attr: Extract a function output_attr()
+ Allow querying all attributes on a file
+ Remove redundant check
+ Remove redundant call to bootstrap_attr_stack()
+ Extract a function collect_all_attrs()
+ Teach prepare_attr_stack() to figure out dirlen itself
+ git-check-attr: Use git_attr_name()
+ Provide access to the name attribute of git_attr
+ git-check-attr: Add tests of command-line parsing
+ git-check-attr: Add missing "&&"
+ Disallow the empty string as an attribute name
+ Remove anachronism from comment
+ doc: Correct git_attr() calls in example code
+ doc: Add a link from gitattributes(5) to git-check-attr(1)
(this branch is used by mh/check-attr-relative.)
* mh/check-attr-relative (2011-08-04) 6 commits
(merged to 'next' on 2011-08-11 at f94550c)
+ test-path-utils: Add subcommand "prefix_path"
+ test-path-utils: Add subcommand "absolute_path"
+ git-check-attr: Normalize paths
+ git-check-attr: Demonstrate problems with relative paths
+ git-check-attr: Demonstrate problems with unnormalized paths
+ git-check-attr: test that no output is written to stderr
(this branch uses mh/check-attr-listing.)
* jk/http-auth-keyring (2011-08-03) 13 commits
(merged to 'next' on 2011-08-03 at b06e80e)
+ credentials: add "getpass" helper
+ credentials: add "store" helper
+ credentials: add "cache" helper
+ docs: end-user documentation for the credential subsystem
+ http: use hostname in credential description
+ allow the user to configure credential helpers
+ look for credentials in config before prompting
+ http: use credential API to get passwords
+ introduce credentials API
+ http: retry authentication failures for all http requests
+ remote-curl: don't retry auth failures with dumb protocol
+ improve httpd auth tests
+ url: decode buffers that are not NUL-terminated
Looked mostly reasonable except for the limitation that it is not clear
how to deal with a site at which a user needs to use different passwords
for different repositories.
* js/ref-namespaces (2011-07-21) 5 commits
(merged to 'next' on 2011-07-25 at 5b7dcfe)
+ ref namespaces: tests
+ ref namespaces: documentation
+ ref namespaces: Support remote repositories via upload-pack and receive-pack
+ ref namespaces: infrastructure
+ Fix prefix handling in ref iteration functions
* rc/histogram-diff (2011-08-08) 12 commits
(merged to 'next' on 2011-08-11 at 684dfd1)
+ xdiff/xhistogram: drop need for additional variable
+ xdiff/xhistogram: rely on xdl_trim_ends()
+ xdiff/xhistogram: rework handling of recursed results
+ xdiff: do away with xdl_mmfile_next()
(merged to 'next' on 2011-08-03 at f9e2328)
+ Make test number unique
(merged to 'next' on 2011-07-25 at 3351028)
+ xdiff/xprepare: use a smaller sample size for histogram diff
+ xdiff/xprepare: skip classification
+ teach --histogram to diff
+ t4033-diff-patience: factor out tests
+ xdiff/xpatience: factor out fall-back-diff function
+ xdiff/xprepare: refactor abort cleanups
+ xdiff/xprepare: use memset()
* rr/revert-cherry-pick-continue (2011-08-08) 18 commits
- revert: Propagate errors upwards from do_pick_commit
- revert: Introduce --continue to continue the operation
- revert: Don't implicitly stomp pending sequencer operation
- revert: Remove sequencer state when no commits are pending
- reset: Make reset remove the sequencer state
- revert: Introduce --reset to remove sequencer state
- revert: Make pick_commits functionally act on a commit list
- revert: Save command-line options for continuing operation
- revert: Save data for continuing after conflict resolution
- revert: Don't create invalid replay_opts in parse_args
- revert: Separate cmdline parsing from functional code
- revert: Introduce struct to keep command-line options
- revert: Eliminate global "commit" variable
- revert: Rename no_replay to record_origin
- revert: Don't check lone argument in get_encoding
- revert: Simplify and inline add_message_to_msg
- config: Introduce functions to write non-standard file
- advice: Introduce error_resolve_conflict
Will merge to "next".
^ permalink raw reply
* Re: Suggestions to make git easier to understand
From: Jonathan Nieder @ 2011-08-11 22:16 UTC (permalink / raw)
To: Philippe Vaucher; +Cc: git, Rafael Magana
In-Reply-To: <CAGK7Mr5T4-DBK7rXeH-1=SNu5HBOEkLBW=CAh5Lhf7oHKjFAiw@mail.gmail.com>
Hi Philippe,
Philippe Vaucher wrote:
> http://raflabs.com/blogs/silence-is-foo/2011/04/07/staging-area-index-cache-git/
>
> I thought it made some good points about git being kinda confusing,
> for example sentences like "Changed but not updated" in git status
> could use a better sentence like "Changed but not in the index".
Sounds reasonable (well, with some more precise wording to reflect
that this means "changed but not all changes are reflected in the
index").
> Maybe
> --cached could have an alias like --index-only for things to be more
> intuitive as well.
>
> `git rm --index-only somefile` is more understandable than `git rm
> --cached somefile` imho.
>
> Also, in ls-files, --stage could maybe use an alias like --contents
> for it to be more self-explanatory.
These suggestions also seem sane. Please send patches
(Documentation/SubmittingPatches explains how) so we can refine them
and fix this.
Thanks much,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 2/5] fast-import: don't fail on omitted committer name
From: Junio C Hamano @ 2011-08-11 22:06 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, SASAKI Suguru
In-Reply-To: <1313058070-4774-3-git-send-email-divanorama@gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
> diff --git a/fast-import.c b/fast-import.c
> index 7cc2262..ed1f7c9 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -1973,6 +1973,10 @@ static char *parse_ident(const char *buf)
> size_t name_len;
> char *ident;
>
> + /* ensure there is a space delimiter even if there is no name */
> + if (*buf == '<')
> + --buf;
> +
This is somewhat cryptic, even though it may be correct, especially if the
reader of the code does not know that this function is called by the
caller after reading "author " (or committer/tagger) and buf points at one
byte beyond that SP after the string that specifies the kind of the
person, hence "--buf" [*1*] makes the subsequent strncpy() start copying
from that SP which makes the result correct.
Perhaps an additional comment before the function is in order?
Thanks.
[Footnote]
*1* by the way, as pure style thing, I think our codebase favors to use
post-*crement, i.e. "buf--", if you are doing pre/post-*crement purely for
its side effect.
^ permalink raw reply
* Re: [PATCH 5/6] sequencer: Expose API to cherry-picking machinery
From: Jonathan Nieder @ 2011-08-11 21:56 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, Junio C Hamano, Christian Couder, Daniel Barkalow,
Jeff King
In-Reply-To: <1313088705-32222-6-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> +++ b/sequencer.c
> @@ -1,8 +1,809 @@
[...]
> +static const char * const revert_usage[] = {
> + "git revert [options] <commit-ish>",
> + "git revert <subcommand>",
> + NULL
> +};
[...]
> +++ b/sequencer.h
[...]
> @@ -25,4 +50,7 @@ struct replay_insn_list {
> */
> void remove_sequencer_state(int aggressive);
>
> +void sequencer_parse_args(int argc, const char **argv, struct replay_opts *opts);
Another thought. I wonder if it's possible to leave
sequencer_parse_args() private to builtin/revert.c, making the split
a little more logical:
- the builtin takes responsibility for its commandline interface
- the library takes over once the builtin has figured out what the
user wanted.
(If another command wants to reuse some subset of cherry-pick/revert's
commandline options, an appropriate function can always be exposed
later.)
^ permalink raw reply
* Re: [PATCH v2] t3900: do not reference numbered arguments from the test script
From: Junio C Hamano @ 2011-08-11 21:49 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Johannes Sixt, Jeff King, git, Michael J Gruber,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20110811071155.GA28213@elie.gateway.2wire.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Johannes Sixt wrote:
>
>> Remove it because -m is optional and the test case
>> does not check for it. There are tests in t7500 that check combinations of
>> --squash and -m.
>
> That's a comfort. Looks obviously good to me, fwiw.
Yeah, looks sane. Thanks everybody.
^ permalink raw reply
* Re: t5800-*.sh: Intermittent test failures
From: Sverre Rabbelier @ 2011-08-11 21:39 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list, Jeff King, Jonathan Nieder, Junio C Hamano
In-Reply-To: <4E417CB4.50007@ramsay1.demon.co.uk>
Heya,
On Tue, Aug 9, 2011 at 20:30, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> The git-fast-import is hung in the read() syscall waiting for data which will
> never arrive. This is because the git(fast-export) process, started by the above
> git(push), executes (producing it's data on stdout) and completes successfully
> and exits *before* the above git-fast-import process starts.
>
> I haven't looked to see how the git(fast-export)/git-fast-import processes are
> plumbed together, but there seems to be a synchronization problem somewhere ...
This seems odd, before the fast-export process is even started it's
stdout are wired to the stdin of the helper (and thus the fast-import
process). What indication do you have that fast-import hasn't started
and that fast-export has finished?
Also, you say git remote-test everywhere, but it should be git
remote-testgit, typo?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox