* 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
* 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: 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
* [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
* [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 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 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 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 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 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
* 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
* 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
* Re: "malloc failed"
From: Johannes Schindelin @ 2009-01-27 18:02 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <878wow7pth.fsf@mcbain.luannocracy.com>
Hi,
On Tue, 27 Jan 2009, David Abrahams 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.
Hah! My first UGFWIINI contender! Unfortunately, I listed that purpose
explicitely already...
> 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.
Yes, I am surprised, too. I would expect that some kind of arbitrary
user-specifiable limit hit you. Haven't had time to look at the code,
though.
Ciao,
Dscho
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Johannes Schindelin @ 2009-01-27 18:08 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git, spearce, Thomas Rast, Björn Steinbrink
In-Reply-To: <20090127092117.d13f24e7.stephen@exigencecorp.com>
Hi,
On Tue, 27 Jan 2009, Stephen Haberman wrote:
> > 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?
Yes, this will still work. AFAICT this is actually how git
--no-interactive -p is implemented...
> (Er, maybe I can just use rebase-p...I forget why [1] is using the
> GIT_EDITOR=: with -i.)
See above... :-)
> 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.
Maybe teach git pull about --rebase=preserve[-merges] and
branch.<name>.rebase=preserve[-merges]?
> 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.
I always meant to handle that in the fast-forward handling of pick_one().
> 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.
Well, let's see how things turn out once I use the patches for my own
work...
Thanks,
Dscho
^ permalink raw reply
* Re: friendlier names
From: Johannes Schindelin @ 2009-01-27 18:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Abrahams, git
In-Reply-To: <20090127153837.GB1321@spearce.org>
Hi,
On Tue, 27 Jan 2009, Shawn O. Pearce 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.
Actually, it was known by the name "dircache" back then :-)
Ciao,
Dscho
^ permalink raw reply
* Re: rebase failure if commit message looks like a patch
From: Johannes Schindelin @ 2009-01-27 18:15 UTC (permalink / raw)
To: Anton; +Cc: git
In-Reply-To: <loom.20090127T173025-125@post.gmane.org>
Hi,
On Tue, 27 Jan 2009, Anton wrote:
> I have found a strange behaviour of "git rebase", present in following
> versions:
That is a known issue. Please work around it with redoing the rebase with
-m.
I could imagine that we should scan the commit messages before actually
running rebase, and either activate -m, or escape the "diff" with a
backslash (as is frequently done with "From" in mails).
Ciao,
Dscho
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Tim Visher @ 2009-01-27 18:24 UTC (permalink / raw)
To: Johannes Gilger; +Cc: git
In-Reply-To: <glkvpp$fvr$1@ger.gmane.org>
Well, I ended up going with Cygwin. Didn't feel like the hassle of
all of the rest of that stuff. Thanks so much, everyone. :)
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: Anyone have access to 64-bit Vista?
From: Stephen Haberman @ 2009-01-27 18:24 UTC (permalink / raw)
To: Geoffrey Lee; +Cc: git
In-Reply-To: <83d7aaa40901270130g3bebb3d6we4839b567f310e46@mail.gmail.com>
> I'm trying to develop for TortoiseGit on a 64-bit Vista SP1 system,
> but I'm having trouble registering the shell extensions with explorer.
> I'm hoping somebody else here who has access to 64-bit Vista can tell
> me if TortoiseGit runs on their machine?
It kind of works on my Vista 64-bit system--I do not see the shell
extensions in the native Windows Explorer (which is 64 bit), but I do
see the shell extensions in an Explorer replacement I use (Xplorer2)
that is 32-bit.
I've seen other oddities in 32-bit vs. 64-bit programs--e.g. my alt tab
replacement (Joe), which is 32-bit, works great with 32-bit programs
but cannot remove focus from 64-bit programs (IE, Windows Explorer,
etc.). Ironically, very few of the programs I use are 64-bit, so I get
by with the alt tab replacement.
- Stephen
^ permalink raw reply
* Re: Building Documentation in Cygwin
From: Tim Visher @ 2009-01-27 18:27 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <c115fd3c0901270944p7a4b6cc5n5dfe9b2f268f038c@mail.gmail.com>
On Tue, Jan 27, 2009 at 12:44 PM, Tim Visher <tim.visher@gmail.com> wrote:
>> 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!
Well, I take that back. I built the docs successfully on the machine
that is connected to the net. I couldn't build them on the offline
box. Currently my solution is to build them on this box and then
manually move them over to the offline box. It'd be nice to not have
to do this though... :\
Anyway, further help is appreciated! :)
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: friendlier names
From: Junio C Hamano @ 2009-01-27 18:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Abrahams, git
In-Reply-To: <20090127153837.GB1321@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> 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.
This part is a bit misleading, if not completely incorrect.
Since day 1, the entity we now call "the index aka staging area" has been
just that. It was originally called "cache" and it implemented a cache of
_contents_ that are meant to go in the tree the next commit records. It
was renamed to the "index" because it is an index, which you can consult
with a pathname as the key to get to the _contents_ as its value.
It never was "list of pathnames" without _contents_. So it was a staging
area from day one.
The way to update the cache was called "update-cache" then "update-index".
Because it usually is much rare to actually add a new entry to the index
than updating an existing entry in the index, the command had a safeguard
against "update-cache a-newfile" without explicit request from the user to
say "oh by the way I know I am adding new entries". "git add" came much
later to give you a shorthand for "update-index --add". Updating existing
entries in the index was still done with "update-index".
Later Nico taught (after much discussion) "git add" to also serve as
"update-index" for existing entries in the index.
We could have called it "git update-index" when we did that switch-over,
because the operation is exactly that --- updating the index.
But the name somehow stuck.
> 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...
Yeah, you may have to consider the possibility that that particular
training lingo is inconsistent with the rest of the system, exactly
because it came from outside.
^ permalink raw reply
* Re: Building Documentation in Cygwin
From: Junio C Hamano @ 2009-01-27 18:32 UTC (permalink / raw)
To: Tim Visher; +Cc: Tay Ray Chuan, git
In-Reply-To: <c115fd3c0901271027s61a33273lfe9dd702a66aac6@mail.gmail.com>
Tim Visher <tim.visher@gmail.com> writes:
> On Tue, Jan 27, 2009 at 12:44 PM, Tim Visher <tim.visher@gmail.com> wrote:
>
>>> 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!
>
> Well, I take that back. I built the docs successfully on the machine
> that is connected to the net. I couldn't build them on the offline
> box. Currently my solution is to build them on this box and then
> manually move them over to the offline box. It'd be nice to not have
> to do this though... :\
>
> Anyway, further help is appreciated! :)
The xml toolchain has a tendency to download dtds from the original source
with a way for you (typically your distribution) to tell it to use a
locally installed version. "Can build online, fail when offline" is a
sign that it is not using the local copy.
^ permalink raw reply
* Re: Valgrind updates
From: Linus Torvalds @ 2009-01-27 18:55 UTC (permalink / raw)
To: Johannes Schindelin, zlib
Cc: Mark Brown, Jeff King, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901271742430.3586@pacific.mpi-cbg.de>
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
>
> 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.
Hmm. The zlib faq has a note about zlib doing a conditional on
uninitialized memory that doesn't matter, and that is what the suppression
should be about (to avoid a warning about "Conditional jump or move
depends on uninitialised value").
But that one is documented to not matter for the actual output (zlib
FAQ#36).
It's possible that zlib really does leave padding bytes around that
literally don't matter, and that don't get initialized. That really would
be bad, because it means that the output of git wouldn't be repeatable.
But I doubt this is the case - original git used to actually do the SHA1
over the _compressed_ data, which was admittedly a totally and utterly
broken design (and we fixed it), but it did work. Maybe it worked by luck,
but I somehow doubt it.
Some googling did find this:
http://mailman.few.vu.nl/pipermail/sysprog/2008-October/000298.html
which looks very similar: an uninitialized byte in the middle of a
deflate() packet.
Anyway, I'm just going to Cc 'zlib@gzip.org', since this definitely is
_not_ the same issue as in the FAQ, and we're not the only ones seeing it.
For the zlib people: the code is literally this:
/* Set it up */
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, zlib_compression_level);
size = 8 + deflateBound(&stream, len+hdrlen);
compressed = xmalloc(size);
/* Compress it */
stream.next_out = compressed;
stream.avail_out = size;
/* First header.. */
stream.next_in = (unsigned char *)hdr;
stream.avail_in = hdrlen;
while (deflate(&stream, 0) == Z_OK)
/* nothing */;
/* Then the data itself.. */
stream.next_in = buf;
stream.avail_in = len;
ret = deflate(&stream, Z_FINISH);
if (ret != Z_STREAM_END)
die("unable to deflate new object %s (%d)", sha1_to_hex(sha1), ret);
ret = deflateEnd(&stream);
if (ret != Z_OK)
die("deflateEnd on object %s failed (%d)", sha1_to_hex(sha1), ret);
size = stream.total_out;
if (write_buffer(fd, compressed, size) < 0)
die("unable to write sha1 file");
and valgrind complains that the "write_buffer()" call will touch an
uninitialized byte (just one byte, and in the _middle_ of the buffer, no
less):
> Yet, the buffer in question is 195 bytes, stream.total_count (which
> totally agrees with size - stream.avail_out) says it is 58 bytes, and
> valgrind says that the byte with offset 51 is uninitialized.
The thing to note here is that what we are passing in to "write_buffer()"
is _exactly_ what zlib deflated for us:
- 'compressed' is the allocation, and is what we used to initialize
'stream.next_out' with (at the top of the code sequence above)
- 'size' is gotten from 'stream.total_out' at the end of the compression.
Maybe the zlib people can tell us that we're idiots and the above is
buggy, but maybe there is a real bug in zlib. Maybe it's triggered by our
use of using two different input buffers to deflate() (ie we compress the
header first, and then the body of the actual data, and put it all in one
single output buffer), which may be unusual usage of zlib routines and may
be why there aren't tons of reports of this.
(Our use of just depending on deflate() returning Z_BUF_ERROR after
consuming all of the header data is probably also "unusual", but the
manual explicitly says that it's not fatal and that deflate can be called
again with more buffers).
Oh Gods of zlib, please hear our plea for clarification..
Linus
^ permalink raw reply
* Re: friendlier names
From: Jakub Narebski @ 2009-01-27 19:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, David Abrahams, git
In-Reply-To: <7vwscgy56b.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> 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...
[...]
> The way to update the cache was called "update-cache" then "update-index".
> Because it usually is much rare to actually add a new entry to the index
> than updating an existing entry in the index, the command had a safeguard
> against "update-cache a-newfile" without explicit request from the user to
> say "oh by the way I know I am adding new entries". "git add" came much
> later to give you a shorthand for "update-index --add". Updating existing
> entries in the index was still done with "update-index".
>
> Later Nico taught (after much discussion) "git add" to also serve as
> "update-index" for existing entries in the index.
>
> We could have called it "git update-index" when we did that switch-over,
> because the operation is exactly that --- updating the index.
>
> But the name somehow stuck.
[...]
It is a bit of pity that "git add" was overloaded to also add new
contents and not only add new file (and its contents!), instead of
having new command "git stage" to be porcelain version of
"git update-index" porcelain. And perhaps "git resolved" to only
mark resolved entries (so e.g. "git resolved ." would not add new
files, nor add new contents of files which were not in conflict).
Now we have to explain that "git add" adds new contents... OTOH
it is perhaps good idea to emphasize differences between Git and
other lesser^W SCMs. ;-) And introduce "git add -N"...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Building Documentation in Cygwin
From: Tim Visher @ 2009-01-27 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git
In-Reply-To: <7vskn4y4zt.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 1:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> The xml toolchain has a tendency to download dtds from the original source
> with a way for you (typically your distribution) to tell it to use a
> locally installed version. "Can build online, fail when offline" is a
> sign that it is not using the local copy.
Sounds like we're on the same page. I'm not familiar enough with any
of these tools to know how to do anything about that. Does anyone
know how to explicitly inform xmlto to use a local DTD? I have it
installed, as far as I know, via cygwin (the docbook-xml42 package)
but I don't know how to tell xmlto about it.
Thanks in advance!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: friendlier names
From: Junio C Hamano @ 2009-01-27 19:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, David Abrahams, git
In-Reply-To: <m37i4gy2z6.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> It is a bit of pity that "git add" was overloaded to also add new
> contents and not only add new file (and its contents!), instead of
> having new command "git stage" to be porcelain version of
> "git update-index" porcelain. And perhaps "git resolved" to only
> mark resolved entries (so e.g. "git resolved ." would not add new
> files, nor add new contents of files which were not in conflict).
I do not think so.
People who are taught with various means (including "git stage" alias)
understand that you prepare the contents you want to record in the commit
you are about to make by updating the contents registered in the index aka
staging area, then you do not need "git resolved".
You resolve, you have the desired content in your work tree, and you
register the updated contents from your work tree to the index aka staging
area, in exactly the same way as you do when you want to include updated
contents for any commit.
^ 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