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 +0100 en-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