From 8a45bb6b10f42ef0529171e340b714f6096903fd Mon Sep 17 00:00:00 2001
From: Johannes Schindelin
Date: Mon, 9 Mar 2009 00:17:48 +0100
Subject: [PATCH] Housekeeping on Monday, 9th of March, Anno Domini MMIX, at
the hour of the Rat
Signed-off-by: Johannes Schindelin
---
blog.rss | 89 ++++++++++++++++++++++++---------------------------
source-1233277286.txt | 41 ------------------------
2 files changed, 41 insertions(+), 89 deletions(-)
delete mode 100644 source-1233277286.txt
diff --git a/blog.rss b/blog.rss
index 4d73b9c859..7a1b366afc 100644
--- a/blog.rss
+++ b/blog.rss
@@ -5,9 +5,49 @@
http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html
A few stories told by Dscho
-Sun, 08 Mar 2009 03:29:50 +0100
+Mon, 09 Mar 2009 00:17:48 +0100en-us
+So, what is missing from my rebase-i-p branch?
+http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236554268
+http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236554268
+Mon, 09 Mar 2009 00:17:48 +0100
+rebase-i-p branch?
+
+I regularly use rebase -i -p these days, to update my personal Git
+tree (which used to be my-next).
+
+There are a few things missing before I can start assembling a patch
+series for submission:
+
+
+
I need to handle the commit parents which are outside of the rebased
+ones properly. In other words, when a commit is picked whose parent is
+not rebased, it needs to be rebased onto $ONTO.
+
The patch which uses patch-id to generate DROPPED directly also tries to
+consolidate the handling of DROPPED commits by putting them into REWRITTEN
+instead of DROPPED, but that breaks the tests. So, this patch needs to be
+split.
+
I want to introduce one more command, rephrase, which allows you to
+modify the commit message, and nothing more, and halt, which does the
+same as edit without pick. Then there needs to be a new test script
+for those commands, and this will be an early patch series.
+
Time. I need time, desperately. If my day job was not as exciting as it
+is, I would have more time for Git. As it is, I have to budget my time so
+that I get anything done at all.
+
+
+These issues have been postponed due to Steffen taking a well-deserved
+vacation, which means that I have to act as msysGit maintainer again.
+
+And this coming week, I will have other things to do in all likeliness, so
+that I expect to be able to submit a rebase -i -p patch series only next
+week. If not then, due to a heavy workload, it will be postponed to early
+April.
+
+Oh well, the joys of being excited by several competing projects! ☺]]>
+
+New Git for Windows version
http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236479389
http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1236479389
@@ -315,52 +355,5 @@ walker which will fake octopus merges (or a series of two-parent merges)
whenever it finds a perl of non-merge commits that are theoretically
independent, i.e. whose patches apply cleanly.]]>
-
-More valgrind fun
-http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233277286
-http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233277286
-Fri, 30 Jan 2009 02:01:26 +0100
-
-So I spent quite a number of hours on that funny zlib/valgrind issue. The
-thing is, zlib people claim that even if their code accesses uninitialized
-memory, it does not produce erroneous data (by cutting out the results of the
-uninitialized data, which is cheaper than checking for the end of the buffer
-in an unaligned manner), so zlib will always be special for valgrind.
-
-However, the bug I was chasing is funny, and different from said issue. zlib
-deflates an input buffer to an output buffer that is exactly 58 bytes long.
-But valgrind claims that the 52nd of those bytes is uninitialized, and only
-that one.
-
-But it is not. It must be 0x2c, otherwise zlib refuses to inflate the
-buffer.
-
-Now, I went into a debugging frenzy, and finally found out that zlib just
-passes fine (with the default suppressions because of the "cute" way it
-uses uninitialized memory), except when it is compiled with UNALIGNED_OK
-defined.
-
-Which Ubuntu does, of course. Ubuntu, the biggest forker of all.
-
-The bad part is that it sounds like a bug in valgrind, and I could imagine
-that it is an issue of an optimized memcpy() that copies int by int, and
-that valgrind misses out on the fact that a part of that int is actually
-not uninitialized.
-
-But my debugging session's results disagree with that.
-
-With the help of Julian Seward, the original author of valgrind, I instrumented
-zlib's source code so that valgrind checks earlier if the byte is initialized
-or not, to find out where the reason of the issue lies.
-
-The sad part is that when I added the instrumentation to both the end of
-the while() loop in compress_block() in zlib's trees.c, and just after the
-while() loop (whose condition is a plain variable < variable comparison,
-nothing fancy, certainly not changing any memory), only the latter catches
-a valgrind error.
-
-And that is truly strange.]]>
-
diff --git a/source-1233277286.txt b/source-1233277286.txt
deleted file mode 100644
index 4c5d7bd1de..0000000000
--- a/source-1233277286.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-More valgrind fun
-
-So I spent quite a number of hours on that funny zlib/valgrind issue. The
-thing is, zlib people claim that even if their code accesses uninitialized
-memory, it does not produce erroneous data (by cutting out the results of the
-uninitialized data, which is cheaper than checking for the end of the buffer
-in an unaligned manner), so zlib will always be special for valgrind.
-
-However, the bug I was chasing is funny, and different from said issue. zlib
-deflates an input buffer to an output buffer that is exactly 58 bytes long.
-But valgrind claims that the 52nd of those bytes is uninitialized, and _only_
-that one.
-
-But it is not. It must be 0x2c, otherwise zlib refuses to inflate the
-buffer.
-
-Now, I went into a debugging frenzy, and finally found out that zlib just
-passes fine (with the default suppressions because of the "cute" way it
-uses uninitialized memory), _except_ when it is compiled with UNALIGNED_OK
-defined.
-
-Which Ubuntu does, of course. Ubuntu, the biggest forker of all.
-
-The bad part is that it sounds like a bug in valgrind, and I _could_ imagine
-that it is an issue of an optimized memcpy() that copies int by int, and
-that valgrind misses out on the fact that a part of that int is actually
-_not_ uninitialized.
-
-But my debugging session's results disagree with that.
-
-With the help of Julian Seward, the original author of valgrind, I instrumented
-zlib's source code so that valgrind checks earlier if the byte is initialized
-or not, to find out where the reason of the issue lies.
-
-The sad part is that when I added the instrumentation to both the _end_ of
-the while() loop in compress_block() in zlib's trees.c, and just _after_ the
-while() loop (whose condition is a plain ''variable < variable'' comparison,
-nothing fancy, certainly not changing any memory), only the _latter_ catches
-a valgrind error.
-
-And that is truly strange.
--
2.11.4.GIT