* Re: Heads up: rebase -i -p will be made sane again
From: Johannes Schindelin @ 2009-01-27 17:59 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git
In-Reply-To: <20090127085418.e113ad5a.stephen@exigencecorp.com>
Hi,
On Tue, 27 Jan 2009, Stephen Haberman wrote:
> > As for the design bug I want to fix: imagine this history:
> >
> > ------A
> > / /
> > / /
> > ---- B
> > \ \
> > \ \
> > C-----D-----E = HEAD
> >
> > A, C and D touch the same file, and A and D agree on the contents.
> >
> > Now, rebase -p A does the following at the moment:
> >
> > ------A-----E' = HEAD
> > / /
> > / /
> > ---- B
> >
> > In other words, C is truly forgotten, and it is pretended that D never
> > happened, either. That is exactly what test case 2 in t3410 tests for
> > [*1*].
> >
> > This is insane.
>
> Agreed.
Good! I already feared that you would be disagreeing with me.
> Does this mean you're just getting rid of the code that calls "rev list
> --cherry-pick"?
Not exactly. The idea of rebasing is to stay on top of an upstream. If
that upstream has your changes already, you do not want to reapply them --
even with --preserve-merges.
Now, a merge cannot be sent as a patch mail, for good reasons. So
whatever merge might look like yours, it is not. So it is your
responsibility to say that yours is obsolete, and delete it from the
rebase script.
If your merge is in upstream (because a pull-request was heeded, for
example), then you will not see the commits anyway.
> A few times I've pondered just removing the --cherry-pick/drop commit
> part of rebase-p, but assumed it was there for a reason.
I will find the "dropped" commits using git log -p | git patch-id.
It is still nice to tell the user if she wants to merge a parent that is
already in upstream, so I would not like to miss out on that information.
> > [*1*] The code in t3410 was not really easy to read, even if there was
> > an explanation what it tried to do, but the test code was inconsitent,
> > sometimes tagging, sometimes not, sometimes committing with -a,
> > sometimes "git add"ing first, yet almost repetitive.
> >
> > In my endeavor not only to understand it, and either fix my code or
> > the code in t3410, I refactored it so that others should have a much
> > easier time to understand what it actually does.
>
> Thanks for cleaning it up.
>
> I recently saw a test of yours use a `test_commit` bash function that I
> really like. My last patch submission debacle had a patch cleaning up
> t3411 by introducing `test_commit`--I can brave `git send-email` again
> if you have any interest in me resending it.
Heh... so I sent that part of the patches. Hopefully they will get in
soon, as they should be rather obvious, and I have a lot more to come...
Ciao,
Dscho
^ permalink raw reply
* rebase failure if commit message looks like a patch
From: Anton @ 2009-01-27 17:50 UTC (permalink / raw)
To: git
I have found a strange behaviour of "git rebase", present in following versions:
git 1.6.1, linux,
git 1.6.0.4, cygwin
if the commit message of one of revisions on local branch
containing something, what looks like patch:
------------------ bad-commit-message { ---------------
changeset a1 - feature added
--- a0 2009-01-25 10:09:05.953125000 +0100
+++ ./r/a 2009-01-25 10:15:20.093750000 +0100
@@ -1,5 +1,5 @@
-1
+1 - upstream
2
3
4
-5
+5 - feature
------------------ bad-commit-message } ---------------
Following shell script reproduces the bug for me:
------------------ show-bug.sh { ---------------
#!/bin/bash
rm -rf r # clean-up
mkdir r # repo dir
cd r
git init
cd ..
cp a0 r/a
cd r
git add a
git ci -m "initial addition of a0"
git br feature
git co feature
cd ..
cp a1 r/a
cd r
git add a
## no bug
#git ci -m "changeset a1 - feature added"
# bug
git ci -F ../bad-commit-message
git co master
cd ..
cp a2 r/a
cd r
git add a
git ci -m "changeset a2 - upstream revision"
git co feature
git rebase master
------------------ show-bug.sh } ---------------
produces the error on final rebase attempt:
First, rewinding head to replay your work on top of it...
Applying: changeset a1 - feature added
error: r/a: does not exist in index
fatal: sha1 information is lacking or useless (r/a).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
In case one uses
# no bug
git ci -m "changeset a1 - feature added"
instead of
# bug
git ci -F ../bad-commit-message
The final rebase succeded !
Content of other files:
---------------- a0 { -------------------
1
2
3
4
5
---------------- a0 } -------------------
---------------- a1 { -------------------
1
2
3
4
5 - feature
---------------- a1 } -------------------
---------------- a2 { -------------------
1 - upstream
2
3
4
5
---------------- a2 } -------------------
--
Anton
^ permalink raw reply
* [PATCH 6/6] Simplify t3412
From: Johannes Schindelin @ 2009-01-27 17:49 UTC (permalink / raw)
To: Stephen Haberman, Thomas Rast; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271844340.3586@pacific.mpi-cbg.de>
Use the newly introduced test_commit() and test_merge() helpers.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Thomas, this touches your code.
t/t3412-rebase-root.sh | 30 +++++++++---------------------
1 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
index 6359580..39f7768 100755
--- a/t/t3412-rebase-root.sh
+++ b/t/t3412-rebase-root.sh
@@ -6,24 +6,16 @@ Tests if git rebase --root --onto <newparent> can rebase the root commit.
'
. ./test-lib.sh
+. ../lib-rebase.sh
+
test_expect_success 'prepare repository' '
- echo 1 > A &&
- git add A &&
- git commit -m 1 &&
- echo 2 > A &&
- git add A &&
- git commit -m 2 &&
+ test_commit 1 A &&
+ test_commit 2 A &&
git symbolic-ref HEAD refs/heads/other &&
rm .git/index &&
- echo 3 > B &&
- git add B &&
- git commit -m 3 &&
- echo 1 > A &&
- git add A &&
- git commit -m 1b &&
- echo 4 > B &&
- git add B &&
- git commit -m 4
+ test_commit 3 B &&
+ test_commit 1b A 1 &&
+ test_commit 4 B
'
test_expect_success 'rebase --root expects --onto' '
@@ -103,9 +95,7 @@ test_expect_success 'pre-rebase got correct input (5)' '
test_expect_success 'set up merge history' '
git checkout other^ &&
git checkout -b side &&
- echo 5 > C &&
- git add C &&
- git commit -m 5 &&
+ test_commit 5 C &&
git checkout other &&
git merge side
'
@@ -132,9 +122,7 @@ test_expect_success 'set up second root and merge' '
git symbolic-ref HEAD refs/heads/third &&
rm .git/index &&
rm A B C &&
- echo 6 > D &&
- git add D &&
- git commit -m 6 &&
+ test_commit 6 D &&
git checkout other &&
git merge third
'
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 5/6] Simplify t3411
From: Johannes Schindelin @ 2009-01-27 17:48 UTC (permalink / raw)
To: Stephen Haberman, Thomas Rast; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271844340.3586@pacific.mpi-cbg.de>
Use test_commit() and test_merge(). This way, it is harder to forget to
tag, or to call test_tick before committing.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t3411-rebase-preserve-around-merges.sh | 65 ++++++++----------------------
1 files changed, 17 insertions(+), 48 deletions(-)
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index 6a1586a..6533505 100755
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -21,27 +21,13 @@ set_fake_editor
# -- C1 --
test_expect_success 'setup' '
- touch a &&
- touch b &&
- git add a &&
- git commit -m A1 &&
- git tag A1
- git add b &&
- git commit -m B1 &&
- git tag B1 &&
- git checkout -b branch &&
- touch c &&
- git add c &&
- git commit -m C1 &&
- git checkout master &&
- touch d &&
- git add d &&
- git commit -m D1 &&
- git merge branch &&
- touch f &&
- git add f &&
- git commit -m F1 &&
- git tag F1
+ test_commit A1 &&
+ test_commit B1 &&
+ test_commit C1 &&
+ git reset --hard B1 &&
+ test_commit D1 &&
+ test_merge E1 C1 &&
+ test_commit F1
'
# Should result in:
@@ -52,7 +38,7 @@ test_expect_success 'setup' '
#
test_expect_success 'squash F1 into D1' '
FAKE_LINES="1 squash 3 2" git rebase -i -p B1 &&
- test "$(git rev-parse HEAD^2)" = "$(git rev-parse branch)" &&
+ test "$(git rev-parse HEAD^2)" = "$(git rev-parse C1)" &&
test "$(git rev-parse HEAD~2)" = "$(git rev-parse B1)" &&
git tag E2
'
@@ -70,32 +56,15 @@ test_expect_success 'squash F1 into D1' '
# And rebase G1..M1 onto E2
test_expect_success 'rebase two levels of merge' '
- git checkout -b branch2 A1 &&
- touch g &&
- git add g &&
- git commit -m G1 &&
- git checkout -b branch3 &&
- touch h
- git add h &&
- git commit -m H1 &&
- git checkout -b branch4 &&
- touch i &&
- git add i &&
- git commit -m I1 &&
- git tag I1 &&
- git checkout branch3 &&
- touch j &&
- git add j &&
- git commit -m J1 &&
- git merge I1 --no-commit &&
- git commit -m K1 &&
- git tag K1 &&
- git checkout branch2 &&
- touch l &&
- git add l &&
- git commit -m L1 &&
- git merge K1 --no-commit &&
- git commit -m M1 &&
+ test_commit G1 &&
+ test_commit H1 &&
+ test_commit I1 &&
+ git checkout -b branch3 H1 &&
+ test_commit J1 &&
+ test_merge K1 I1 &&
+ git checkout -b branch2 G1 &&
+ test_commit L1 &&
+ test_merge M1 K1 &&
GIT_EDITOR=: git rebase -i -p E2 &&
test "$(git rev-parse HEAD~3)" = "$(git rev-parse E2)" &&
test "$(git rev-parse HEAD~2)" = "$(git rev-parse HEAD^2^2~2)" &&
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 4/6] Simplify t3410
From: Johannes Schindelin @ 2009-01-27 17:48 UTC (permalink / raw)
To: Stephen Haberman, Thomas Rast; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271844340.3586@pacific.mpi-cbg.de>
Use test_commit() and test_merge(), reducing the code while making the
intent clearer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Stephen, this and the next one touches your code.
t/t3410-rebase-preserve-dropped-merges.sh | 126 +++++++++--------------------
1 files changed, 37 insertions(+), 89 deletions(-)
diff --git a/t/t3410-rebase-preserve-dropped-merges.sh b/t/t3410-rebase-preserve-dropped-merges.sh
index 5816415..0669b48 100755
--- a/t/t3410-rebase-preserve-dropped-merges.sh
+++ b/t/t3410-rebase-preserve-dropped-merges.sh
@@ -11,6 +11,8 @@ rewritten.
'
. ./test-lib.sh
+. ../lib-rebase.sh
+
# set up two branches like this:
#
# A - B - C - D - E
@@ -22,47 +24,17 @@ rewritten.
# where B, D and G touch the same file.
test_expect_success 'setup' '
- : > file1 &&
- git add file1 &&
- test_tick &&
- git commit -m A &&
- git tag A &&
- echo 1 > file1 &&
- test_tick &&
- git commit -m B file1 &&
- : > file2 &&
- git add file2 &&
- test_tick &&
- git commit -m C &&
- echo 2 > file1 &&
- test_tick &&
- git commit -m D file1 &&
- : > file3 &&
- git add file3 &&
- test_tick &&
- git commit -m E &&
- git tag E &&
- git checkout -b branch1 A &&
- : > file4 &&
- git add file4 &&
- test_tick &&
- git commit -m F &&
- git tag F &&
- echo 3 > file1 &&
- test_tick &&
- git commit -m G file1 &&
- git tag G &&
- : > file5 &&
- git add file5 &&
- test_tick &&
- git commit -m H &&
- git tag H &&
- git checkout -b branch2 F &&
- : > file6 &&
- git add file6 &&
- test_tick &&
- git commit -m I &&
- git tag I
+ test_commit A file1 &&
+ test_commit B file1 1 &&
+ test_commit C file2 &&
+ test_commit D file1 2 &&
+ test_commit E file3 &&
+ git checkout A &&
+ test_commit F file4 &&
+ test_commit G file1 3 &&
+ test_commit H file5 &&
+ git checkout F &&
+ test_commit I file6
'
# A - B - C - D - E
@@ -72,68 +44,44 @@ test_expect_success 'setup' '
# I -- G2 -- J -- K I -- K
# G2 = same changes as G
test_expect_success 'skip same-resolution merges with -p' '
- git checkout branch1 &&
+ git checkout H &&
! git merge E &&
- echo 23 > file1 &&
- git add file1 &&
- git commit -m L &&
- git checkout branch2 &&
- echo 3 > file1 &&
- git commit -a -m G2 &&
+ test_commit L file1 23 &&
+ git checkout I &&
+ test_commit G2 file1 3 &&
! git merge E &&
- echo 23 > file1 &&
- git add file1 &&
- git commit -m J &&
- echo file7 > file7 &&
- git add file7 &&
- git commit -m K &&
- GIT_EDITOR=: git rebase -i -p branch1 &&
- test $(git rev-parse branch2^^) = $(git rev-parse branch1) &&
+ test_commit J file1 23 &&
+ test_commit K file7 file7 &&
+ git rebase -i -p L &&
+ test $(git rev-parse HEAD^^) = $(git rev-parse L) &&
test "23" = "$(cat file1)" &&
- test "" = "$(cat file6)" &&
- test "file7" = "$(cat file7)" &&
-
- git checkout branch1 &&
- git reset --hard H &&
- git checkout branch2 &&
- git reset --hard I
+ test "I" = "$(cat file6)" &&
+ test "file7" = "$(cat file7)"
'
# A - B - C - D - E
# \ \ \
-# F - G - H -- L \ --> L
-# \ | \
-# I -- G2 -- J -- K I -- G2 -- K
+# F - G - H -- L2 \ --> L2
+# \ | \
+# I -- G3 --- J2 -- K2 I -- G3 -- K2
# G2 = different changes as G
test_expect_success 'keep different-resolution merges with -p' '
- git checkout branch1 &&
+ git checkout H &&
! git merge E &&
- echo 23 > file1 &&
- git add file1 &&
- git commit -m L &&
- git checkout branch2 &&
- echo 4 > file1 &&
- git commit -a -m G2 &&
+ test_commit L2 file1 23 &&
+ git checkout I &&
+ test_commit G3 file1 4 &&
! git merge E &&
- echo 24 > file1 &&
- git add file1 &&
- git commit -m J &&
- echo file7 > file7 &&
- git add file7 &&
- git commit -m K &&
- ! GIT_EDITOR=: git rebase -i -p branch1 &&
+ test_commit J2 file1 24 &&
+ test_commit K2 file7 file7 &&
+ test_must_fail git rebase -i -p L2 &&
echo 234 > file1 &&
git add file1 &&
- GIT_EDITOR=: git rebase --continue &&
- test $(git rev-parse branch2^^^) = $(git rev-parse branch1) &&
+ git rebase --continue &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse L2) &&
test "234" = "$(cat file1)" &&
- test "" = "$(cat file6)" &&
- test "file7" = "$(cat file7)" &&
-
- git checkout branch1 &&
- git reset --hard H &&
- git checkout branch2 &&
- git reset --hard I
+ test "I" = "$(cat file6)" &&
+ test "file7" = "$(cat file7)"
'
test_done
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 3/6] lib-rebase.sh: introduce test_commit() and test_merge() helpers
From: Johannes Schindelin @ 2009-01-27 17:47 UTC (permalink / raw)
To: Stephen Haberman, Thomas Rast; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271844340.3586@pacific.mpi-cbg.de>
Often we just need to add a commit with a given (short) name, that will
be tagged with the same name. Now, relatively complicated graphs can be
constructed easily and in a clear fashion:
test_commit A &&
test_commit B &&
git checkout A &&
test_commit C &&
test_merge D B
will construct this graph:
A - B
\ \
C - D
For simplicity, files of the same name (but in lower case, to avoid
a warning about ambiguous names) will be committed, with the commit
message as contents.
If you need to provide a different file/different contents, you can use
the more explicit form
test_commit $MESSAGE $FILENAME $CONTENTS
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This may want to live in test-lib.sh instead.
t/lib-rebase.sh | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index cda7778..37430f3 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -46,3 +46,29 @@ EOF
test_set_editor "$(pwd)/fake-editor.sh"
chmod a+x fake-editor.sh
}
+
+# Call test_commit with the arguments "<message> [<file> [<contents>]]"
+#
+# This will commit a file with the given contents and the given commit
+# message. It will also add a tag with <message> as name.
+#
+# Both <file> and <contents> default to <message>.
+
+test_commit () {
+ file=$2
+ test -z "$2" && file=$(echo "$1" | tr 'A-Z' 'a-z')
+ echo ${3-$1} > $file &&
+ git add $file &&
+ test_tick &&
+ git commit -m $1 &&
+ git tag $1
+}
+
+# Call test_merge with the arguments "<message> <commit>", where <commit>
+# can be a tag pointing to the commit-to-merge.
+
+test_merge () {
+ test_tick &&
+ git merge -m $1 $2 &&
+ git tag $1
+}
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 2/6] lib-rebase.sh: Document what set_fake_editor() does
From: Johannes Schindelin @ 2009-01-27 17:46 UTC (permalink / raw)
To: Stephen Haberman, Thomas Rast; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271844340.3586@pacific.mpi-cbg.de>
rnyn
Make it easy for other authors to use rebase tests' fake-editor.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Separated from 1/6 to make the code move more obvious.
t/lib-rebase.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 8c8caab..cda7778 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -1,5 +1,17 @@
#!/bin/sh
+# After setting the fake editor with this function, you can
+#
+# - override the commit message with $FAKE_COMMIT_MESSAGE,
+# - amend the commit message with $FAKE_COMMIT_AMEND
+# - check that non-commit messages have a certain line count with $EXPECT_COUNT
+# - rewrite a rebase -i script with $FAKE_LINES in the form
+#
+# "[<lineno1>] [<lineno2>]..."
+#
+# If a line number is prefixed with "squash" or "edit", the respective line's
+# command will be replaced with the specified one.
+
set_fake_editor () {
echo "#!${SHELL_PATH-/bin_sh}" >fake-editor.sh
cat >> fake-editor.sh <<\EOF
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 1/6] t3404 & t3411: undo copy&paste
From: Johannes Schindelin @ 2009-01-27 17:45 UTC (permalink / raw)
To: Stephen Haberman, Thomas Rast; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271844340.3586@pacific.mpi-cbg.de>
Rather than copying and pasting, which is prone to lead to fixes
missing in one version, move the fake-editor generator to t/t3404/.
While at it, fix a typo that causes head-scratching: use
${SHELL_PATH-/bin/sh} instead of $SHELL_PATH.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/lib-rebase.sh | 36 ++++++++++++++++++++++++++++
t/t3404-rebase-interactive.sh | 37 +++--------------------------
t/t3411-rebase-preserve-around-merges.sh | 38 +++--------------------------
3 files changed, 44 insertions(+), 67 deletions(-)
create mode 100644 t/lib-rebase.sh
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
new file mode 100644
index 0000000..8c8caab
--- /dev/null
+++ b/t/lib-rebase.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+set_fake_editor () {
+ echo "#!${SHELL_PATH-/bin_sh}" >fake-editor.sh
+ cat >> fake-editor.sh <<\EOF
+case "$1" in
+*/COMMIT_EDITMSG)
+ test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
+ test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
+ exit
+ ;;
+esac
+test -z "$EXPECT_COUNT" ||
+ test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
+ exit
+test -z "$FAKE_LINES" && exit
+grep -v '^#' < "$1" > "$1".tmp
+rm -f "$1"
+cat "$1".tmp
+action=pick
+for line in $FAKE_LINES; do
+ case $line in
+ squash|edit)
+ action="$line";;
+ *)
+ echo sed -n "${line}s/^pick/$action/p"
+ sed -n "${line}p" < "$1".tmp
+ sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
+ action=pick;;
+ esac
+done
+EOF
+
+ test_set_editor "$(pwd)/fake-editor.sh"
+ chmod a+x fake-editor.sh
+}
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 2cc8e7a..3592403 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -10,6 +10,10 @@ that the result still makes sense.
'
. ./test-lib.sh
+. ../lib-rebase.sh
+
+set_fake_editor
+
# set up two branches like this:
#
# A - B - C - D - E
@@ -61,39 +65,6 @@ test_expect_success 'setup' '
git tag I
'
-echo "#!$SHELL_PATH" >fake-editor.sh
-cat >> fake-editor.sh <<\EOF
-case "$1" in
-*/COMMIT_EDITMSG)
- test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
- test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
- exit
- ;;
-esac
-test -z "$EXPECT_COUNT" ||
- test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
- exit
-test -z "$FAKE_LINES" && exit
-grep -v '^#' < "$1" > "$1".tmp
-rm -f "$1"
-cat "$1".tmp
-action=pick
-for line in $FAKE_LINES; do
- case $line in
- squash|edit)
- action="$line";;
- *)
- echo sed -n "${line}s/^pick/$action/p"
- sed -n "${line}p" < "$1".tmp
- sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
- action=pick;;
- esac
-done
-EOF
-
-test_set_editor "$(pwd)/fake-editor.sh"
-chmod a+x fake-editor.sh
-
test_expect_success 'no changes are a nop' '
git rebase -i F &&
test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch2" &&
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
index aacfaae..6a1586a 100755
--- a/t/t3411-rebase-preserve-around-merges.sh
+++ b/t/t3411-rebase-preserve-around-merges.sh
@@ -5,44 +5,14 @@
test_description='git rebase preserve merges
-This test runs git rebase with and tries to squash a commit from after a merge
-to before the merge.
+This test runs git rebase with -p and tries to squash a commit from after
+a merge to before the merge.
'
. ./test-lib.sh
-# Copy/paste from t3404-rebase-interactive.sh
-echo "#!$SHELL_PATH" >fake-editor.sh
-cat >> fake-editor.sh <<\EOF
-case "$1" in
-*/COMMIT_EDITMSG)
- test -z "$FAKE_COMMIT_MESSAGE" || echo "$FAKE_COMMIT_MESSAGE" > "$1"
- test -z "$FAKE_COMMIT_AMEND" || echo "$FAKE_COMMIT_AMEND" >> "$1"
- exit
- ;;
-esac
-test -z "$EXPECT_COUNT" ||
- test "$EXPECT_COUNT" = $(sed -e '/^#/d' -e '/^$/d' < "$1" | wc -l) ||
- exit
-test -z "$FAKE_LINES" && exit
-grep -v '^#' < "$1" > "$1".tmp
-rm -f "$1"
-cat "$1".tmp
-action=pick
-for line in $FAKE_LINES; do
- case $line in
- squash|edit)
- action="$line";;
- *)
- echo sed -n "${line}s/^pick/$action/p"
- sed -n "${line}p" < "$1".tmp
- sed -n "${line}s/^pick/$action/p" < "$1".tmp >> "$1"
- action=pick;;
- esac
-done
-EOF
+. ../lib-rebase.sh
-test_set_editor "$(pwd)/fake-editor.sh"
-chmod a+x fake-editor.sh
+set_fake_editor
# set up two branches like this:
#
--
1.6.1.482.g7d54be
^ permalink raw reply related
* [PATCH 0/6] Simplifications of some 'rebase' tests
From: Johannes Schindelin @ 2009-01-27 17:45 UTC (permalink / raw)
To: Stephen Haberman, Thomas Rast; +Cc: git
In-Reply-To: <20090127085418.e113ad5a.stephen@exigencecorp.com>
While working on the rebase revamp, I had to fix a few tests (the design
bug I described earlier, and fallout from the new "goto" and "merge"
functions).
These are just the cleanups, they should not change any functionality,
but make everything more readable by providing simple test_commit() and
test_merge() wrappers.
Note: the test_commit() and test_merge() wrappers might be generic enough
to put them into test-lib.sh for a wider audience.
Johannes Schindelin (6):
t3404 & t3411: undo copy&paste
lib-rebase.sh: Document what set_fake_editor() does
lib-rebase.sh: introduce test_commit() and test_merge() helpers
Simplify t3410
Simplify t3411
Simplify t3412
t/lib-rebase.sh | 74 +++++++++++++++++
t/t3404-rebase-interactive.sh | 37 +--------
t/t3410-rebase-preserve-dropped-merges.sh | 126 +++++++++--------------------
t/t3411-rebase-preserve-around-merges.sh | 103 +++++-------------------
t/t3412-rebase-root.sh | 30 ++-----
5 files changed, 145 insertions(+), 225 deletions(-)
create mode 100644 t/lib-rebase.sh
^ permalink raw reply
* Re: Building Documentation in Cygwin
From: Tim Visher @ 2009-01-27 17:44 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901270832o1a176691nab5500a86c531795@mail.gmail.com>
On Tue, Jan 27, 2009 at 11:32 AM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> try running xmlto in verbose, what does it output?
$ xmlto -v -m callouts.xsl man git-add.xml
Format script: /usr/share/xmlto/format/docbook/man
Convert to troff
Real stylesheet:
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
xmllint >/dev/null --xinclude --postvalid
/home/tvishe01/projects/git/Documentation/git-add.xml
xmlto: input does not validate (status 3)
error : Operation not permitted
/home/tvishe01/projects/git/Documentation/git-add.xml:2: warning:
failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
D DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
^
error : Operation not permitted
warning: failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
Could not load the external subset
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
Document /home/tvishe01/projects/git/Documentation/git-add.xml does not validate
-- cut
It might be germane to mention that I'm attempting to build this on an
offline box.
> you might also want to try getting the cygwin package docbook-xml42.
Sure enough, I didn't have that installed. Turns out I should've done
that part first too, as it appears to have fixed my problem. Thanks
so much!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* gitk run from subdir and "find commit touching paths"
From: Sitaram Chamarty @ 2009-01-27 17:14 UTC (permalink / raw)
To: git
If I run gitk from a subdirectory, and then try to find a
commit touching a path, it doesn't work. No movement of
cursor on "Next/Prev".
Running from the main project directory makes it work ok --
you can go "Next" or "Prev" finding other commits that
touched the same path.
Is this a known problem? I couldn't find it in the mailing
list archives.
Thanks,
Sitaram
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 16:54 UTC (permalink / raw)
To: Mark Brown; +Cc: Linus Torvalds, Jeff King, Junio C Hamano, git
In-Reply-To: <20090127131404.GA11870@sirena.org.uk>
Hi,
On Tue, 27 Jan 2009, Mark Brown wrote:
> On Tue, Jan 27, 2009 at 05:26:34AM +0100, Johannes Schindelin wrote:
>
> > I suspected that zlib does something "cute" with alignments, i.e. that
> > it writes a possibly odd number of bytes, but then rounds up the
> > buffer to the next multiple of two of four bytes.
>
> I don't recall anything along those lines in zlib but it does generate
> warnings with valgrind which require overrides - it has at least one
> unrolled loop which roll on beyond initialised memory (but keep within
> memory that zlib knows it has allocated). It rolls back the results of
> the loop before producing output, but it's possible that some unused
> bits in the stream may be derived from the results.
That is what I suspected, but the data contradict this:
- accesses to all offsets between 0 and 50 and 52 and 58 (one _more_ than
indicated as valid by stream.total_count!) do not trigger any message in
valgrind.
- access to offset 51, which is well _within_ the boundaries, and even
well outside the range of a stray alignment issue, _does_ trigger a
valgrind message.
So either valgrind gets it wrong (which I find rather unlikely), or zlib
really does not write to that offset.
Or, and I think that makes most sense so far, valgrind has not really
ignored the initialization of byte number 52 in that buffer which partly
depended on an uninitialized value (but does not matter, maybe due to
Huffman cutoff or something similar).
Come to think of it, the word "suppression" is probably a good indicator
that valgrind never claimed it would mark the zlib buffer as properly
initialized.
Sorry for the noise, then,
Dscho
^ permalink raw reply
* Re: friendlier names
From: David Abrahams @ 2009-01-27 16:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090127153837.GB1321@spearce.org>
on Tue Jan 27 2009, "Shawn O. Pearce" <spearce-AT-spearce.org> wrote:
> David Abrahams <dave@boostpro.com> wrote:
>>
>> For example, why couldn't the "index" be called the "stage" instead?
>> That, along with knowing that "git add" was a synonym for "git stage"
>> would have flattened the learning curve considerably for me.
>
> Historical reasons...
>
> Waaay back the "index" was an index of the files git knows about in
> your working directory. It made sense to call it an index, as like
> a book index it was a full listing of what's here, sorted by name.
>
> That's pre-1.0 days. Like the very first version Linus ever
> released. Aka commit e83c5163316f89bfbde7d9ab23ca2e25604af290.
I'm not saying "index" doesn't make sense. It _still_ makes sense. It
just doesn't make as much sense as "stage." Index is a very generic
term; it doesn't communicate enough.
> Much, much later, over many months, the index morphed into what
> you see today, which is a "staging area", accessed by "git add".
>
> This was all incremental, in small parts. Nobody set out to
> design a "staging area" or to have "staging actions". Back
> when it was really the index you updated it with a tool called
> git-update-index. Adding new files required the --add flag.
>
> People found --add annoying, so they wrote "git add" as a
> wrapper around it. But modified existing files still had
> to be updated with git-update-index. Then someone pointed
> out that add of an existing file and add of a new file are
> similiar enough that they should just be the same command,
> "git add".
>
> Only late last October at the GitTogether did we start to talk about
> creating a command called "git stage", because people have started to
> realize we seem to call it a "staging area" as we train newcomers...
Sounds like, from everything you've said, "stage" rather than "index"
would have been just as sensible in the beginning as it is today; it's
just that you have a much nicer interface for working with it.
> The tools are _all_ slowly evolved over time. Nothing in git
> was ever set out from the beginning as a "this is what we are
> going to do". The only part of Git that is like that is the core
> data structure on disk for the object store. That hasn't changed
> since Linus switched from SHA1(COMPRESS(data)) to SHA1(data) for
> the object naming algorithm, and even that was done in the first
> couple of weeks.
OK, thanks for the history lesson. It's good to know someone is paying
attention to these things. Is there any movement toward addressing
them outside of GitTogether talk?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Johannes Schindelin @ 2009-01-27 16:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <497F076F.8060509@viscovery.net>
Hi,
On Tue, 27 Jan 2009, Johannes Sixt wrote:
> We want to catch failures of test-chmtime; but since it appears in a
> pipe, we cannot access its exit code. Therefore, we at least make sure
> that it prints time stamps of all files that are passed on its command
> line.
I use this trick in my valgrind series:
($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
test 0 = "$(cat exit.code)"
Ciao,
Dscho
^ permalink raw reply
* Re: Building Documentation in Cygwin
From: Tay Ray Chuan @ 2009-01-27 16:32 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901270741h2f213b99s31bac8829bd182c2@mail.gmail.com>
Hi,
On Tue, Jan 27, 2009 at 11:41 PM, Tim Visher <tim.visher@gmail.com> wrote:
> $ make install-man
> rm -f doc.dep+ doc.dep
> /usr/bin/perl ./build-docdep.perl >doc.dep+
> mv doc.dep+ doc.dep
> make -C ../ GIT-VERSION-FILE
> make[1]: Entering directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> make[1]: `GIT-VERSION-FILE' is up to date.
> make[1]: Leaving directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> make -C ../ GIT-VERSION-FILE
> make[1]: Entering directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> make[1]: `GIT-VERSION-FILE' is up to date.
> make[1]: Leaving directory `/cygdrive/c/Documents and
> Settings/tvishe01/Desktop/Projects/git'
> rm -f git-add.xml+ git-add.xml
> asciidoc -b docbook -d manpage -f asciidoc.conf \
> -agit_version=1.6.1.1.230.gdfb04 -o git-add.xml+
> git-add.txt
> mv git-add.xml+ git-add.xml
> rm -f git-add.1
> xmlto -m callouts.xsl man git-add.xml
> xmlto: input does not validate (status 3)
hmm i tried running this and this rule passed for me.
try running xmlto in verbose, what does it output? here's mine:
---cut---
$ xmlto -v -m callouts.xsl man git-add.xml
Format script: /usr/share/xmlto/format/docbook/man
Convert to troff
Real stylesheet:
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
xmllint >/dev/null --xinclude --postvalid
/cygdrive/g/temp/git/git/Documentation/git-add.xml
Stylesheet: /tmp/xmlto-xsl.nEUjsh
xsltproc --nonet --xinclude \
-o /tmp/xmlto.MvioXw/git-add.proc \
/tmp/xmlto-xsl.nEUjsh \
/cygdrive/g/temp/git/git/Documentation/git-add.xml
Writing git-add.1 for refentry
---cut---
you might also want to try getting the cygwin package docbook-xml42.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Johannes Schindelin @ 2009-01-27 16:31 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git
In-Reply-To: <20090127062512.GA10487@coredump.intra.peff.net>
Hi,
On Tue, 27 Jan 2009, Jeff King wrote:
> On Thu, Jan 08, 2009 at 04:07:08PM +0100, Johannes Schindelin wrote:
>
> > Just try this with a submodule that has more changes than fit on a
> > screen:
> >
> > $ git -p submodule summary
> >
> > In my tests, it consistently fscks up my console. I wonder if this is
> > related to ea27a18(spawn pager via run_command interface).
>
> OK, here is a patch series that fixes the problem:
>
> 1/3: git: s/run_command/run_builtin/
> 2/3: run_command: handle missing command errors more gracefully
> 3/3: git: use run_command to execute dashed externals
>
> 1 is a cleanup, 2 is infrastructure support, and 3 is the actual fix.
I like the patch series, well designed and concise (especially with the
fixes Hannes proposed).
> There are two potential downsides to the fix:
>
> 1. There is an extra fork and a parent process sitting in memory for
> dashed externals. This is pretty necessary to any fix, since
> something has to wait to do pager cleanup, and we can't rely on the
> child to do so.
Actually, I think this is a good thing; that way, we can catch
segmentation fault properly and display an error message in the pager.
That was not possible previously.
> 2. A failed attempt to execute a dashed external results in an extra
> fork. For builtins, this has no impact, since they take precedence.
> For aliases, though, it means we will do an extra fork before
> realizing that there is no dashed external and trying the alias.
All the more reason to build more programs in :-)
Ciao,
Dscho
^ permalink raw reply
* Building Documentation in Cygwin
From: Tim Visher @ 2009-01-27 15:41 UTC (permalink / raw)
To: git
Hey Everyone,
I've asked this question here before but unfortunately I can't find
the answer in any of the archives. I'm trying to build the
documentation on Windows in Cygwin. Git builds fine, the html docs
build fine, but when I get to the man pages, I get the following
error:
$ make install-man
rm -f doc.dep+ doc.dep
/usr/bin/perl ./build-docdep.perl >doc.dep+
mv doc.dep+ doc.dep
make -C ../ GIT-VERSION-FILE
make[1]: Entering directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
make[1]: `GIT-VERSION-FILE' is up to date.
make[1]: Leaving directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
make -C ../ GIT-VERSION-FILE
make[1]: Entering directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
make[1]: `GIT-VERSION-FILE' is up to date.
make[1]: Leaving directory `/cygdrive/c/Documents and
Settings/tvishe01/Desktop/Projects/git'
rm -f git-add.xml+ git-add.xml
asciidoc -b docbook -d manpage -f asciidoc.conf \
-agit_version=1.6.1.1.230.gdfb04 -o git-add.xml+
git-add.txt
mv git-add.xml+ git-add.xml
rm -f git-add.1
xmlto -m callouts.xsl man git-add.xml
xmlto: input does not validate (status 3)
error : Operation not permitted
/home/tvishe01/projects/git/Documentation/git-add.xml:2: warning:
failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
D DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
^
error : Operation not permitted
warning: failed to load external entity
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
Could not load the external subset
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
Document /home/tvishe01/projects/git/Documentation/git-add.xml
does not validate
make: *** [git-add.1] Error 3
I've fixed this before but I've been thwarted all morning on the
Googles trying to find out what to do. I remember it having something
to do with explicitly telling xmlto not to try to download doctypes or
something. Also, I remember there being pre-built man pages somewhere
that I could download and just manually install.
Anyway, I'm not opposed to either of those routes, I just can't figure
out how to do it personally.
Thanks in advance!
--
http://five.sentenc.es/ - Spend less time on e-mail.
Written using [Emacs](http://www.gnu.org/software/emacs/).
^ permalink raw reply
* Re: friendlier names
From: Shawn O. Pearce @ 2009-01-27 15:38 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <87mydc6a2r.fsf@mcbain.luannocracy.com>
David Abrahams <dave@boostpro.com> wrote:
>
> For example, why couldn't the "index" be called the "stage" instead?
> That, along with knowing that "git add" was a synonym for "git stage"
> would have flattened the learning curve considerably for me.
Historical reasons...
Waaay back the "index" was an index of the files git knows about in
your working directory. It made sense to call it an index, as like
a book index it was a full listing of what's here, sorted by name.
That's pre-1.0 days. Like the very first version Linus ever
released. Aka commit e83c5163316f89bfbde7d9ab23ca2e25604af290.
Much, much later, over many months, the index morphed into what
you see today, which is a "staging area", accessed by "git add".
This was all incremental, in small parts. Nobody set out to
design a "staging area" or to have "staging actions". Back
when it was really the index you updated it with a tool called
git-update-index. Adding new files required the --add flag.
People found --add annoying, so they wrote "git add" as a
wrapper around it. But modified existing files still had
to be updated with git-update-index. Then someone pointed
out that add of an existing file and add of a new file are
similiar enough that they should just be the same command,
"git add".
Only late last October at the GitTogether did we start to talk about
creating a command called "git stage", because people have started to
realize we seem to call it a "staging area" as we train newcomers...
The tools are _all_ slowly evolved over time. Nothing in git
was ever set out from the beginning as a "this is what we are
going to do". The only part of Git that is like that is the core
data structure on disk for the object store. That hasn't changed
since Linus switched from SHA1(COMPRESS(data)) to SHA1(data) for
the object naming algorithm, and even that was done in the first
couple of weeks.
--
Shawn.
^ permalink raw reply
* Re: "malloc failed"
From: David Abrahams @ 2009-01-27 15:32 UTC (permalink / raw)
To: git
In-Reply-To: <20090127152915.GA1321@spearce.org>
on Tue Jan 27 2009, "Shawn O. Pearce" <spearce-AT-spearce.org> wrote:
> David Abrahams <dave@boostpro.com> wrote:
>> I've been abusing Git for a purpose it wasn't intended to serve:
>> archiving a large number of files with many duplicates and
>> near-duplicates. Every once in a while, when trying to do something
>> really big, it tells me "malloc failed" and bails out (I think it's
>> during "git add" but because of the way I issued the commands I can't
>> tell: it could have been a commit or a gc). This is on a 64-bit linux
>> machine with 8G of ram and plenty of swap space, so I'm surprised.
>>
>> Git is doing an amazing job at archiving and compressing all this stuff
>> I'm putting in it, but I have to do it a wee bit at a time or it craps
>> out. Bug?
>
> No, not really. Above you said you are "abusing git for a purpose
> it wasn't intended to serve"...
Absolutely; I want to be upfront about that :-)
> Git was never designed to handle many large binary blobs of data.
They're largely text blobs, although there definitely are a fair share
of binaries.
> It was mostly designed for source code, where the majority of the
> data stored in it is some form of text file written by a human.
>
> By their very nature these files need to be relatively short (e.g.
> under 1 MB each) as no human can sanely maintain a text file that
> large without breaking it apart into different smaller files (like
> the source code for an operating system kernel).
>
> As a result of this approach, the git code assumes it can malloc()
> at least two blocks large enough for each file: one of the fully
> decompressed content, and another for the fully compressed content.
> Try doing git add on a large file and its very likely malloc
> will fail due to ulimit issues, or you just don't have enough
> memory/address space to go around.
Oh, so maybe I'm getting hit by ulimit; I didn't think of that. I could
raise my ulimit to try to get around this.
> git gc likewise needs a good chunk of memory, but it shouldn't
> usually report "malloc failed". Usually in git gc if a malloc fails
> it prints a warning and degrades the quality of its data compression.
> But there are critical bookkeeping data structures where we must be
> able to malloc the memory, and if those fail because we've already
> exhausted the heap early on, then yea, it can fail too.
Thanks much for that, and for reminding me about ulimit.
Cheers,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: friendlier names
From: Felipe Contreras @ 2009-01-27 15:33 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <87mydc6a2r.fsf@mcbain.luannocracy.com>
On Tue, Jan 27, 2009 at 5:30 PM, David Abrahams <dave@boostpro.com> wrote:
>
> I'm absolutely certain I'm not the first person to have raised this
> issue, so feel free to point me at the threads where I can get the
> rationale... but: to me it looks like git's choice of terminology hurts
> its adoption and learnability.
>
> For example, why couldn't the "index" be called the "stage" instead?
> That, along with knowing that "git add" was a synonym for "git stage"
> would have flattened the learning curve considerably for me.
+1
I think several people have mentioned it, and there have been
different possible actions, but nothing concrete AFAIK.
--
Felipe Contreras
^ permalink raw reply
* friendlier names
From: David Abrahams @ 2009-01-27 15:30 UTC (permalink / raw)
To: git
I'm absolutely certain I'm not the first person to have raised this
issue, so feel free to point me at the threads where I can get the
rationale... but: to me it looks like git's choice of terminology hurts
its adoption and learnability.
For example, why couldn't the "index" be called the "stage" instead?
That, along with knowing that "git add" was a synonym for "git stage"
would have flattened the learning curve considerably for me.
Thanks,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: "malloc failed"
From: Shawn O. Pearce @ 2009-01-27 15:29 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <878wow7pth.fsf@mcbain.luannocracy.com>
David Abrahams <dave@boostpro.com> wrote:
> I've been abusing Git for a purpose it wasn't intended to serve:
> archiving a large number of files with many duplicates and
> near-duplicates. Every once in a while, when trying to do something
> really big, it tells me "malloc failed" and bails out (I think it's
> during "git add" but because of the way I issued the commands I can't
> tell: it could have been a commit or a gc). This is on a 64-bit linux
> machine with 8G of ram and plenty of swap space, so I'm surprised.
>
> Git is doing an amazing job at archiving and compressing all this stuff
> I'm putting in it, but I have to do it a wee bit at a time or it craps
> out. Bug?
No, not really. Above you said you are "abusing git for a purpose
it wasn't intended to serve"...
Git was never designed to handle many large binary blobs of data.
It was mostly designed for source code, where the majority of the
data stored in it is some form of text file written by a human.
By their very nature these files need to be relatively short (e.g.
under 1 MB each) as no human can sanely maintain a text file that
large without breaking it apart into different smaller files (like
the source code for an operating system kernel).
As a result of this approach, the git code assumes it can malloc()
at least two blocks large enough for each file: one of the fully
decompressed content, and another for the fully compressed content.
Try doing git add on a large file and its very likely malloc
will fail due to ulimit issues, or you just don't have enough
memory/address space to go around.
git gc likewise needs a good chunk of memory, but it shouldn't
usually report "malloc failed". Usually in git gc if a malloc fails
it prints a warning and degrades the quality of its data compression.
But there are critical bookkeeping data structures where we must be
able to malloc the memory, and if those fail because we've already
exhausted the heap early on, then yea, it can fail too.
--
Shawn.
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Stephen Haberman @ 2009-01-27 15:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce, Thomas Rast, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>
> I am very sorry if somebody actually scripted rebase -i -p (by setting
> GIT_EDITOR with a script), but I am very certain that this cleanup is
> absolutely necessary to make rebase -i -p useful.
I have scripted rebase-i-p, but with GIT_EDITOR=: [1]. I assume this
will still work and just accept the default script?
(Er, maybe I can just use rebase-p...I forget why [1] is using the
GIT_EDITOR=: with -i.)
My primary pain point with rebase-i-p has been rebasing a branch that
has merged in another branch that has a lot of commits on it. E.g.:
a -- b -- c origin/feature
\
d -- e feature
/
... g origin/master
Where e is merging in, say, a latest release that had a few hundred
commits in the master branch. After resolving conflicts/etc. in e, I
want to rebase d..e from a to be on c.
The two problems have been:
1) `git pull` with rebase set uses rebase-i, with no -p, so all of the
commits from the latest release branch that got merged in with e are
flattened/duplicated. This is what [1] tries to fix. I've made
noises about hacking the branch rebase flag but haven't followed
through.
I know this is a git pull issue, but I bring it up because, IIRC, the
t3410 test case came from a scenario where I was rebasing a merge
like e above and due to --cherry-pick dropping a commit (probably e
itself, I'm not sure), rebase-i-p as it existed then broke and
produced a noop. So I set off to get it to do "something" and ended
up introducing the "DROPPED" directory.
2) With manual invocation of `rebase-i-p`, previously you'd get a
laundry list of commits from the e merge that are new to the feature
branch, but since g and its ancestors aren't changing, you don't need
to consider them in the script and so its (potentially a lot of)
noise. This is what the parent probing back port from git sequencer
addressed.
So, I don't mean to rehash old complaints, as I'd love to see the
rebase-i-p code cleaned up by someone who can really refactor it vs. my
hack patches. But I wanted to emphasize the motivation for my hacks over
their implementation so that hopefully you can still address these use
cases in the new version.
Thanks,
Stephen
[1]: http://github.com/stephenh/git-central/blob/master/scripts/pull
^ permalink raw reply
* Re: Heads up: rebase -i -p will be made sane again
From: Stephen Haberman @ 2009-01-27 14:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901271012550.14855@racer>
> Dear list,
Thanks for keeping me on the cc list--several of the later stages of
cruft are my fault, so I don't know that I'll be able to help any more
than commentary on the use cases I was trying to fulfill.
> As for the design bug I want to fix: imagine this history:
>
> ------A
> / /
> / /
> ---- B
> \ \
> \ \
> C-----D-----E = HEAD
>
> A, C and D touch the same file, and A and D agree on the contents.
>
> Now, rebase -p A does the following at the moment:
>
> ------A-----E' = HEAD
> / /
> / /
> ---- B
>
> In other words, C is truly forgotten, and it is pretended that D never
> happened, either. That is exactly what test case 2 in t3410 tests for
> [*1*].
>
> This is insane.
Agreed.
Does this mean you're just getting rid of the code that calls "rev list
--cherry-pick"?
If so, I'd be all for that--I did not introduce it, nor fully understand
its nuances, and t3410 was just a hack to get the behavior of a rebase
with a dropped/cherry picked commit from the previous behavior of being
a no-op to instead do "something".
A few times I've pondered just removing the --cherry-pick/drop commit
part of rebase-p, but assumed it was there for a reason.
Also, yeah, don't treat the test cases in t3410 as "the result should be
this exact DAG" but "the result should be something that is not a
noop/sane".
> [*1*] The code in t3410 was not really easy to read, even if there was an
> explanation what it tried to do, but the test code was inconsitent,
> sometimes tagging, sometimes not, sometimes committing with -a, sometimes
> "git add"ing first, yet almost repetitive.
>
> In my endeavor not only to understand it, and either fix my code or the
> code in t3410, I refactored it so that others should have a much easier
> time to understand what it actually does.
Thanks for cleaning it up.
I recently saw a test of yours use a `test_commit` bash function that I
really like. My last patch submission debacle had a patch cleaning up
t3411 by introducing `test_commit`--I can brave `git send-email` again
if you have any interest in me resending it.
Thanks,
Stephen
^ permalink raw reply
* "malloc failed"
From: David Abrahams @ 2009-01-27 15:04 UTC (permalink / raw)
To: git
I've been abusing Git for a purpose it wasn't intended to serve:
archiving a large number of files with many duplicates and
near-duplicates. Every once in a while, when trying to do something
really big, it tells me "malloc failed" and bails out (I think it's
during "git add" but because of the way I issued the commands I can't
tell: it could have been a commit or a gc). This is on a 64-bit linux
machine with 8G of ram and plenty of swap space, so I'm surprised.
Git is doing an amazing job at archiving and compressing all this stuff
I'm putting in it, but I have to do it a wee bit at a time or it craps
out. Bug?
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
^ 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