Update Monday, 9th of February, Anno Domini MMIX, at the hour of the Buffalo

[git/dscho.git] / blog.rss

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Dscho's blog</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html</link>
<atom:link href="http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=blog.rss" rel="self" type="application/rss+xml"/>
<description>A few stories told by Dscho</description>
<lastBuildDate>Mon, 09 Feb 2009 02:04:49 +0100</lastBuildDate>
<language>en-us</language>
<item>
<title>format-patch --thread and Alpine</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234141489</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234141489</guid>
<pubDate>Mon, 09 Feb 2009 02:04:49 +0100</pubDate>
<description><![CDATA[<i>format-patch --thread</i> and Alpine
</p><p>
I started recently to pipe the output of
<i>git format-patch --cover-letter --stdout ...</i> directly into the
<i>postponed-msgs</i> folder Alpine uses, instead of pasting files into the
mailer.
</p><p>
The idea is to pretend that I continue a postponed mail, but in reality I
never wrote it, <i>format-patch</i> did.
</p><p>
However, I had problems with the <i>--thread</i> option that is implied by
<i>--cover-letter</i>.  Alpine always generated new message IDs without adjusting
the <i>In-reply-to:</i> and <i>References:</i> headers of the other mails.
</p><p>
Now I found out that the reason is that the <i>Fcc:</i> headers were missing in
the mails, and Alpine generated them, making up new message IDs in the process.
</p><p>
Therefore I have an alias now which sets not only the <i>Fcc:</i> header, but also
the <i>To:</i> headers by rewriting the stream using <i>sed</i>.  This is slightly
ugly, but so is the handling of headers in <i>format-patch</i>: if you thought
you could specify arbitrary headers using the command line, you are mistaken:
you can do that only by editing the config.
</p><p>
While at it, I also noticed a bug whereby <i>--thread --in-reply-to=...</i> simply
forgets the <i>--thread</i>.  Maybe this week I will find time to address this bug.]]></description>
</item>
<item>
<title>rebase updates</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234140696</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234140696</guid>
<pubDate>Mon, 09 Feb 2009 01:51:36 +0100</pubDate>
<description><![CDATA[<i>rebase</i> updates
</p><p>
Phew.  The last few days, I was mainly chasing bugs I introduced due to being
too tired to work on the merge-preserving, interactive <i>rebase</i>.
</p><p>
But finally I have something I can start working with.  After my failed
experiment to use git-blame to split topic branches, I will sort the commits
in my <i>my-next</i> branch into topic branches manually.
</p><p>
Then I will add an option to <i>rebase -i -p</i> to rewrite refs which point to
rewritten commits, so that I can have branches <i>rebase-i-p</i>, <i>add-e</i>, etc
and all of them are automatically updated when I <i>rebase -i -p</i> the <i>my-next</i>
branch.
</p><p>
In the process, not only have I learnt the value of the <i>bookmark</i> command,
but made quite a few-much needed cleanups (which make
<i>git-rebase--interactive.sh</i> longer, but much more understandable).
</p><p>
Hopefully Stephan will pick the changes in the "rebase protocol" up, and then
we can have a sequencer with which I can start to make a graphical interactive
rebase using git-gui.  Or gitk.
</p><p>
Maybe.]]></description>
</item>
<item>
<title>The infamous mark command in the rebase command</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234040744</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1234040744</guid>
<pubDate>Sat, 07 Feb 2009 22:05:44 +0100</pubDate>
<description><![CDATA[The infamous <i>mark</i> command in the <i>rebase</i> command
</p><p>
I realized today how easy it is to lose commits with the "merge preserving"
mode of the interactive rebase.  In my case, it was when I tried to move a
bunch of commits from the tip of my branch into a topic branch.
</p><p>
But after moving the commits, I forgot to update the parent of the merge
commit.  Possibly a mark command could have helped.  The very same command
I called a nightmare for usability.
</p><p>
So I was wrong.  Big news.  &#x263a;
</p><p>
However, I think that the syntax "mark :1" is something best left for
machine consumption, not for human beings.
</p><p>
But I have an idea: we could use some garbled commit subject, or in case of
merge parents, the merge subject as some human readable title of the mark.
</p><p>
The rebase script would then look something like this:
</p><p>
<table
                                border=1 bgcolor=white>
                        <tr><td bgcolor=lightblue colspan=3>
                                <pre>                                                                                </pre>
                        </td></tr>
                        <tr><td>
                                <table cellspacing=5 border=0
                                         style="color:black;">
                                <tr><td>
                                        <pre>
pick abcdefg Some ultra cool commit
bookmark ultra-cool
goto upstream
pick hijklmn Some other cool commit
merge parent ultra-cool Merge 'ultra-cool' into master
</pre>
                                </td></tr>
                                </table>
                        </td></tr>
                        </table>
</p><p>
The good news is: I added code that refuses to finish a rebase when there
are commits that were rewritten, but not part of the new HEAD's ancestry.]]></description>
</item>
<item>
<title>New valgrind series</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233707628</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233707628</guid>
<pubDate>Wed, 04 Feb 2009 01:33:48 +0100</pubDate>
<description><![CDATA[New valgrind series
</p><p>
I spent quite some time cleaning up that patch series, and feel pretty
exhausted.
</p><p>
Granted, the new <i>git rebase -i -p</i> does its job without complaint so far
(so much so that I think I'll release a version of my <i>rebase</i> series
soonish), but it <u>is</u> a hassle when you have patches that you have a hard
time to decide upon the order/commit boundaries.
</p><p>
For example, I could imagine that the patch making the location of the
templates independent of the location of the Git binaries should come
<u>before</u> my patch series, and the valgrind specific part should then
be squashed into the first valgrind commit.
</p><p>
Also, it uses two features of valgrind 3.4.0:
</p><p>
<ul>
<li><i>...</i> in the suppression file, and
<li><i>--track-origins=yes</i>
</ul>
</p><p>
The latter is actually the reason I am pretty willing to keep the
requirement of that valgrind version, as it is really, really useful.
</p><p>
I guess we will see what happens to it.]]></description>
</item>
<item>
<title>Problems with split-topic-branches.sh</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233706294</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233706294</guid>
<pubDate>Wed, 04 Feb 2009 01:11:34 +0100</pubDate>
<description><![CDATA[Problems with split-topic-branches.sh
</p><p>
So my little script that should help me to split my topic branches does
not work properly.
</p><p>
First some background: the idea was to let <i>git blame</i> do the hard work
to find overlapping changes, i.e. changes that would conflict when
changing the order (or skipping the first change, on which the next builds).
</p><p>
The first problem with that approach: when lines are <u>removed</u> by one
commit, and the next commit touches the same location, <i>git blame</i> does
not find that the first commit is required by the second.
</p><p>
Therefore I introduced a really slow reverse thing which tries to find
those commits whose removals survived until the parent of a particular
commit, but not further.
</p><p>
However, it does not work properly.  Basically, only context sizes that
span the whole files lead to conflict-free topic branches so far.
</p><p>
As a consequence, I think I'll add an option --sprout to the revision
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.]]></description>
</item>
<item>
<title>More valgrind fun</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233277286</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233277286</guid>
<pubDate>Fri, 30 Jan 2009 02:01:26 +0100</pubDate>
<description><![CDATA[More valgrind fun
</p><p>
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.
</p><p>
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 <u>only</u>
that one.
</p><p>
But it is not.  It must be 0x2c, otherwise zlib refuses to inflate the
buffer.
</p><p>
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), <u>except</u> when it is compiled with UNALIGNED_OK
defined.
</p><p>
Which Ubuntu does, of course.  Ubuntu, the biggest forker of all.
</p><p>
The bad part is that it sounds like a bug in valgrind, and I <u>could</u> 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
<u>not</u> uninitialized.
</p><p>
But my debugging session's results disagree with that.
</p><p>
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.
</p><p>
The sad part is that when I added the instrumentation to both the <u>end</u> of
the while() loop in compress_block() in zlib's trees.c, and just <u>after</u> the
while() loop (whose condition is a plain <i>variable < variable</i> comparison,
nothing fancy, certainly not changing any memory), only the <u>latter</u> catches
a valgrind error.
</p><p>
And that is truly strange.]]></description>
</item>
<item>
<title>Interactive stash</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233193467</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233193467</guid>
<pubDate>Thu, 29 Jan 2009 02:44:27 +0100</pubDate>
<description><![CDATA[Interactive stash
</p><p>
There is an easy way to split a patch:
</p><p>
<table
                                border=1 bgcolor=white>
                        <tr><td bgcolor=lightblue colspan=3>
                                <pre>                                                                                </pre>
                        </td></tr>
                        <tr><td>
                                <table cellspacing=5 border=0
                                         style="color:black;">
                                <tr><td>
                                        <pre>
$ git reset HEAD^
$ git add -i
$ git commit
$ git diff -R HEAD@{1} | git apply --index
$ git commit
</pre>
                                </td></tr>
                                </table>
                        </td></tr>
                        </table>
</p><p>
but it misses out on the fact that the first of both commits does not
reflect the state of the working directory at any time.
</p><p>
So I think something like an interactive <i>stash</i> is needed.  A method
to specify what you want to keep in the working directory, the rest should
be stashed.  The idea would be something like this:
</p><p>
<ol>
<li>Add the desired changes into a temporary index.
<li>Put the rest of the changes in another temporary index.
<li>Stash the latter index.
<li>Synchronize the working directory with the first index.
<li>Clean up temporary indices.
</ol>
</p><p>
Or in code:
</p><p>
<table
                                border=1 bgcolor=white>
                        <tr><td bgcolor=lightblue colspan=3>
                                <pre>                                                                                </pre>
                        </td></tr>
                        <tr><td>
                                <table cellspacing=5 border=0
                                         style="color:black;">
                                <tr><td>
                                        <pre>
$ cp .git/index .git/interactive-stash-1
$ GIT_INDEX_FILE=.git/interactive-stash-1 git add -i
$ cp .git/index .git/interactive-stash-2
$ GIT_INDEX_FILE=.git/interactive-stash-1 git diff -R |
        (GIT_INDEX_FILE=.git/interactive-stash-2 git apply--index)
$ tree=$(GIT_INDEX_FILE=.git/index git write-tree)
$ commit=$(echo Current index | git commit-tree $tree -p HEAD)
$ tree=$(GIT_INDEX_FILE=.git/interactive-stash-2 git write-tree)
$ commit=$(echo Edited out | git commit-tree $tree -p HEAD -p $commit)
$ git update-ref refs/stash $commit
$ GIT_INDEX_FILE=.git/interactive-stash-1 git checkout-index -a -f
$ rm .git/interactive-stash-1 .git/interactive-stash-2
</pre>
                                </td></tr>
                                </table>
                        </td></tr>
                        </table>
</p><p>
This should probably go into <i>git-stash.sh</i>, maybe even with a switch
to start git-gui to do the interactive adding instead of git-add.]]></description>
</item>
<item>
<title>Splitting topic branches</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233154567</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233154567</guid>
<pubDate>Wed, 28 Jan 2009 15:56:07 +0100</pubDate>
<description><![CDATA[Splitting topic branches
</p><p>
One might be put off easily by the overarching use of buzzwords in the
description of how <i>Darcs</i> works.  I, for one, do not expect an intelligent
author when I read <i>Theory of patches</i> and <i>based on quantum physics</i>.
</p><p>
The true story, however, is much simpler, and is actually not that dumb:
Let's call two commits "conflicting" when they contain at least one
overlapping change.
</p><p>
The idea is now: Given a list of commits (not a set, as the order is important),
to sort them into smaller lists such that conflicting commits are in the
sublists ("topic branches") and the sublists are minimal, i.e. no two
non-conflicting commits are in the same sublist.
</p><p>
The idea has flaws, of course, as you can have a patch changing the code,
and another changing the documentation, but splitting a list of commits
in that way is a first step to sort out my <i>my-next</i> mess, where I have
a linear perl of not-necessarily-dependent commits.
</p><p>
And actually, my whole rebase revamp aimed at the clean-up for my own
<i>my-next</i> branch, so I am currently writing a script that can be used
as a GIT_EDITOR for git-rebase which implements the Darcs algorithm.  Kind of:
the result is not implicit, but explicit and can be fixed up later.]]></description>
</item>
<item>
<title>Showing off that you're an Alpine user ... priceless!</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233102919</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233102919</guid>
<pubDate>Wed, 28 Jan 2009 01:35:19 +0100</pubDate>
<description><![CDATA[Showing off that you're an Alpine user ... priceless!
</p><p>
So I was in a hurry to send the patches, and sent all the patches as replies
to the cover-letter, and therefore typed in <i>rnyn</i> all the time, which is the
mantra I need to say to Alpine for <i>Reply</i>, ... include quoted message?
<i>No</i>, ... reply to all recipients? <i>Yes</i>, ... use first role?
<i>No, use default role</i>.
</p><p>
That was pretty embarassing, as it shows everybody that I still do not trust
<i>send-email</i>, and rather paste every single patch by hand.  Which is rather
annoying.
</p><p>
So I started using format-patch today, to output directly to Alpine's
<i>postponed-msgs</i> folder, so that I can do some touchups in the mailer
before sending the patch series on its way.
</p><p>
However, when running format-patch with <i>--thread</i>, it generates Message-ID
strings that Alpine does not like, and therefore replaces.
</p><p>
Oh, well, I'll probably just investigate how the Message-IDs are supposed to
look, and then use sed to rewrite the generated ones by Alpine-friendly ones
during the redirection to <i>postponed-msgs</i>.
</p><p>
But I alread realized that doing it that way is dramatically faster than the
workflow I had before.
</p><p>
And safer: no more <i>rnyn</i>.]]></description>
</item>
<item>
<title>Progress with the interactive rebase preserving merges</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233101919</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233101919</guid>
<pubDate>Wed, 28 Jan 2009 01:18:39 +0100</pubDate>
<description><![CDATA[Progress with the interactive rebase preserving merges
</p><p>
I thought about the "dropped" commits a bit more, after all, and it is
probably a good thing to substitute them by their parent, as Stephen did it.
</p><p>
Imagine that you have merged a branch with two commits.  One is in upstream,
and you want to rebase (preserving merges) onto upstream.  Then you still
want to merge the single commit.
</p><p>
Even better, if there is no commit left, the <i>$REWRITTEN</i> mechanism will
substitute the commit onto which we are rebasing, so a merge will just
result in a fast-forward!
</p><p>
Oh, another thing: merge commits should not have a patch id, as they have
<u>multiple</u> patches.  However, I borked the code long time ago (9c6efa36)
and merges get the patch-id of their diff to the first parent.  Which is
probably wrong.  So I guess I'll have to fix that with my rebase revamp.
</p><p>
So what about a root commit?  If that was dropped, we will just substitute
it with the commit onto which we rebase (as a root commit did not really
have a parent, but will get the onto-commit as new parent)..
</p><p>
Now that I finally realized that t3410 is so strange because of a bug <u>I</u>
introduced, I can finally go about fixing it.]]></description>
</item>
</channel>
</rss>