Unbreak images

[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, 26 Jan 2009 20:14:50 +0100</lastBuildDate>
<language>en-us</language>
<item>
<title>Valgrind takes a loooong time</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232997290</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232997290</guid>
<pubDate>Mon, 26 Jan 2009 20:14:50 +0100</pubDate>
<description><![CDATA[Valgrind takes a loooong time
</p><p>
Yesterday, I started a run on a fast machine, and it took roughly 5.5
hours by the machine's clock.
</p><p>
And of course, I redirected stdout only... *sigh*
</p><p>
Which triggered a Google search how to force redirection of all the output
in the test scripts to a file and the terminal at the same time.
</p><p>
It seems as if that is not easily done.  I tried
<center><table
                                border=1 bgcolor=white>
                        <tr><td bgcolor=lightblue colspan=3>
                                &nbsp;
                        </td></tr>
                        <tr><td>
                                <table cellspacing=5 border=0
                                         style="color:black;">
                                <tr><td>
                                        <pre>
exec >(tee out) 2>&1                                    </pre>
                                </td></tr>
                                </table>
                        </td></tr>
                        </table></center>
</p><p>
but that did not work: it mumbled something about invalid file handles or some
such.
</p><p>
The only solution I found was:
<center><table
                                border=1 bgcolor=white>
                        <tr><td bgcolor=lightblue colspan=3>
                                &nbsp;
                        </td></tr>
                        <tr><td>
                                <table cellspacing=5 border=0
                                         style="color:black;">
                                <tr><td>
                                        <pre>
mkpipe pipe                                    
tee out < pipe &
exec > pipe 2>&1                </pre>
                                </td></tr>
                                </table>
                        </td></tr>
                        </table></center>
</p><p>
That is a problem for parallel execution, though, so I am still looking for a
better way to do it.
</p><p>
Once I have the output, it is relatively easy to analyze it, as I already
made a script which disects the output into valgrind output and the test
case it came from, then groups by common valgrind output and shows the
result to the user.]]></description>
</item>
<item>
<title>A day full of rebase... and a little valgrind</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232927812</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232927812</guid>
<pubDate>Mon, 26 Jan 2009 00:56:52 +0100</pubDate>
<description><![CDATA[A day full of rebase... and a little valgrind
</p><p>
I think that I am progressing nicely with my rebase -p work, so much so
that I will soon be able to use it myself to work on topic branches <u>and</u>
rebase all the time without much hassle.
</p><p>
In other words, I would like to be able to rebase all my topic branches
to Junio's <i>next</i> branch whenever that has new commits.  With a single
rebase.
</p><p>
And finally, I got the idea of the thing Stephen implemented for dropped
commits; however, I am quite sure I do not like it.
</p><p>
So what are "dropped" commits?
</p><p>
When you rebase, chances are that the upstream already has applied at
least some of your patches.  So we filter those out with <i>--cherry-pick</i>.
Stephen calls those "dropped" commits.
</p><p>
Then he goes on to reinvent the "$REWRITTEN" system: a directory containing
the mappings of old commit names to new commit names.  That is easily fixed.
</p><p>
But worse, he substitutes the dropped commits with their <u>parents</u>, instead
of substituting them with the corresponding commits in upstream.
</p><p>
I guess this will be a medium-sized fight on the mailing list, depending
how much energy Stephen wants to put in to defend his strategy.
</p><p>
Anyway, I finally got to a point where only three of the tests are failing,
t3404, t3410 and t3412.  Somewhat disappointing is t3404, as its name pretends
not to exercize -p at all.  Oh well, I guess I'll see what is broken tomorrow.
</p><p>
Another part of the day was dedicated to the Valgrind patch series, which
should give us yet another level of code quality.
</p><p>
After having confused myself with several diverging/obsolete branches, I did
indeed finally manage to send that patch series off.  Woohoo.]]></description>
</item>
<item>
<title>Regular diff with word coloring (as opposed to word diff)</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232888842</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232888842</guid>
<pubDate>Sun, 25 Jan 2009 14:07:22 +0100</pubDate>
<description><![CDATA[Regular diff with word coloring (as opposed to word diff)
</p><p>
You know, if I were a bit faster with everything I do, I could do so much more!
</p><p>
For example, Junio's idea that you could keep showing a regular diff, only
coloring the words that have been removed/deleted.
</p><p>
Just imagine looking at the diff of a long line in LaTeX source code.  It
should be much nicer to the eye to see the complete removed/added sentences
instead of one sentence with colored words in between, disrupting your read
flow.
</p><p>
Compare these two versions:
</p><p>
Regular diff with colored words:
<blockquote><tt>
-This sentence has a <font color=red>tyop</font> in it.<br>
+This sentence has a <font color=green>typo</font> in it.<br>
</tt></blockquote>
</p><p>
Word diff:
<blockquote><tt>
This sentence has a <font color=red>tyop</font><font color=green>typo</font> in it.<br>
</tt></blockquote>
</p><p>
And it should not be hard to do at all!
</p><p>
In <i>diff&#95;words&#95;show()</i>, we basically get the minus lines as
<i>diff&#95;words->minus</i> and the plus lines as <i>diff&#95;words->plus</i>.  The
function then prepares the word lists and calls the xdiff engine to do all the
hard work, analyzing the result from xdiff and printing the lines in
<i>fn&#95;out&#95;diff&#95;words&#95;aux()</i>.
</p><p>
So all that would have to be changed would be to <u>record</u> the positions
of the removed/added words instead of outputting them, and at the end printing
the minus/plus buffers using the recorded information to color the words.
</p><p>
This would involve
</p><p>
<ul>
<li>adding two new members holding the offsets in the <i>diff&#95;words</i>
struct,
<li>having a special handling for that mode in
<i>fn&#95;out&#95;diff&#95;words&#95;aux()</i> that appends the offsets and
returns,
<li>adding a function <i>show&#95;lines&#95;with&#95;colored&#95;words()</i> that
outputs a buffer with a given prefix ('-' or '+') and coloring the words at
given offsets with a given color,
<li>modify <i>diff&#95;words&#95;show()</i> to call that function for the "special
case: only removal" and at the end of the function, and
<li> disabling the <i>fwrite()</i> at the end of <i>diff<u>words</u>show()</i> for that
mode.
</ul>
</p><p>
Of course, the hardest part is to find a nice user interface for that.  Maybe
<i>--colored-words</i>? &#x263a;]]></description>
</item>
<item>
<title>Ideas for a major revamp of the --preserve-merges handling in git rebase</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232828715</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232828715</guid>
<pubDate>Sat, 24 Jan 2009 21:25:15 +0100</pubDate>
<description><![CDATA[Ideas for a major revamp of the <i>--preserve-merges</i> handling in <i>git rebase</i>
</p><p>
As probably everybody agrees, the code to preserve merges is a big mess 
right now.
</p><p>
Worse, the whole concept of "pick <merge-sha1>" just does not fly well.
</p><p>
So I started a <u>major</u> cleanup, which happens to reduce the code very 
nicely so far.
</p><p>
It will take a few days to flesh out, I guess, but these are the major 
ideas of my work:
</p><p>
<b>pick $sha1</b><br>
<blockquote>will only work on non-merges in the future.</blockquote>
<b>merge $sha1 [$sha1...] was $sha1 Merge ...</b><br>
<blockquote>will merge the given list of commits into the current HEAD, for 
        the user's reference and to keep up-to-date what was rewritten, 
        the original merge is shown after the keyword "was" (which is not 
        a valid SHA-1, luckily).</blockquote>
<b>goto $sha1</b><br>
<blockquote>will reset the HEAD to the given commit.</blockquote>
<b>$sha1'</b><br>
<blockquote>for merge and goto, if a $sha1 ends in a single quote, the 
        rewritten commit is substituted (if there is one).</blockquote>
</p><p>
Example:
</p><p>
<pre>
A - B - - - E 
  \       /
    C - D
</pre>
</p><p>
could yield this TODO script:
</p><p>
<pre>
        pick A
        pick C
        pick D
        goto A'
        pick B
        merge D' was E
</pre>
</p><p>
This should lead to a much more intuitive user experience.
</p><p>
I am very sorry if somebody actually scripted <i>rebase -i -p</i> (by setting 
GIT_EDITOR with a script), but I am very certain that this cleanup is 
absolutely necessary to make <i>rebase -i -p</i> useful.]]></description>
</item>
<item>
<title>Thoughts about interactive rebase</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232778113</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232778113</guid>
<pubDate>Sat, 24 Jan 2009 07:21:53 +0100</pubDate>
<description><![CDATA[Thoughts about <i>interactive rebase</i>
</p><p>
Somebody mentioned that my <i>my-next</i> branch is a mess, as it mixes all
kinds of topics.
</p><p>
That is undeniably true, however, there is a good reason that I do not
have a lot of topic branches: I work on more than just one computer.
</p><p>
To make sure that I do not lose a commit by mistake, I always <i>rebase -i</i>
the <i>my-next</i> branch of the computer I happen to work on on top of the
<i>my-next</i> branch I fetch from <a href=http://repo.or.cz>repo.or.cz</a>.
</p><p>
To rebase a lot of topic branches at the same time seems a bit complicated.
But that is actually what the <i>-p</i> option (preserve merges) is all about.
</p><p>
The only problem is that the code for <i>rebase -i -p</i> has been messed up
recently, quite successfully, I might add.
</p><p>
Worse, some people are pushing for a completely and total unintuitive syntax.
</p><p>
So maybe I will start to work on <i>-p</i> again, for my own use (I should learn
to heed the principle more: work on things I can use myself).
</p><p>
My current idea is to implement a "goto" statement that will jump to another
commit.  To make it easily usable, I will add the semantics that "goto" will
always try to go to the <u>rewritten</u> version of the given commit; if the user
wanted to have the original commit, she has to paste the unabbreviated commit
name.
</p><p>
The more I think about it, the more I actually like this idea &#x263a;
</p><p>
Of course, working on this little project means that I will have to cope with
that ugly code again.  *urgh*]]></description>
</item>
<item>
<title>Git Logos</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232745071</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232745071</guid>
<pubDate>Fri, 23 Jan 2009 22:11:11 +0100</pubDate>
<description><![CDATA[Git Logos
</p><p>
The other day, when I did not exactly have too much time on my hands, but
definitely too much motivation, I played around creating several logos.
</p><p>
An ambigram (if you turn it 180 degrees around the appropriate axis, it looks
exactly the same as unrotated):
</p><p>
<center>
        <table border=0>
                <tr>
                        <td align=center>
                                <embed type="image/svg+xml"
                                        src="2630BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-ambigram.svg" width=317 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=2630BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-ambigram.svg>git-ambigram.svg</a>
                        </td>
                </tr>
        </table>
</center>
</p><p>
A play on gitk:
</p><p>
<center>
        <table border=0>
                <tr>
                        <td align=center>
                                <embed type="image/svg+xml"
                                        src="2670BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-gitk-logo.svg" width=325 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=2670BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-gitk-logo.svg>git-gitk-logo.svg</a>
                        </td>
                </tr>
        </table>
</center>
</p><p>
A play on the test you have to go through before getting new glasses:
</p><p>
<center>
        <table border=0>
                <tr>
                        <td align=center>
                                <embed type="image/svg+xml"
                                        src="2689BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-visual-test.svg" width=325 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=2689BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-visual-test.svg>git-visual-test.svg</a>
                        </td>
                </tr>
        </table>
</center>
</p><p>
This is Henrik Nyh's logo (converted to .svg by yours truly):
</p><p>
<center>
        <table border=0>
                <tr>
                        <td align=center>
                                <embed type="image/svg+xml"
                                        src="2708BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=gitlogo.svg" width=165 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=2708BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=gitlogo.svg>gitlogo.svg</a>
                        </td>
                </tr>
        </table>
</center>
</p><p>
And of course, the original logo...
</p><p>
<center>
        <table border=0>
                <tr>
                        <td align=center>
                                <embed type="image/svg+xml"
                                        src="2727BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=original-git-logo.svg" width=165 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=2727BLOBPLAIN;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=original-git-logo.svg>original-git-logo.svg</a>
                        </td>
                </tr>
        </table>
</center>
</p><p>
Maybe some of you have fun with them...]]></description>
</item>
<item>
<title>How to deal with files that are not source code when merging</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232742582</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232742582</guid>
<pubDate>Fri, 23 Jan 2009 21:29:42 +0100</pubDate>
<description><![CDATA[How to deal with files that are not source code when merging
</p><p>
Last week, one of the mentors of last year's <a href=http://code.google.com/soc>
Summer of Code</a> mentioned the idea that merge strategies are in dear need
for file types other than source code.
</p><p>
I think this idea is awesome, even if I cannot bring myself to believe that
any of the file types would make a good Summer of Code project: either they
are too complicated (think raster images such as .png or even .jpg), or they
are too straight-forward (think LaTeX, where all that is needed is a good
graphical user interface to inspect the three versions: <i>ours</i>, <i>baseline</i>
and <i>theirs</i>).
</p><p>
The LaTeX idea would be a good project for me to mentor, though: I have a
pretty clear idea how it should be done; I just lack the time (and motivation)
to do it myself.
</p><p>
As for OpenOffice text documents, vector graphics (such as .svg), or more
specific data such as spreadsheets, I think that all of these are really
difficult: the problem is not so much the implementation (i.e. the programming
part of it), but the design.
</p><p>
This design should involve much more than a Summer of Code project is about:
you would need to survey users' expectations, and at least the mentor -- if
not the student -- would need to be an expert in usability questions, which
is rather unlikely in the realm of Open Source.
</p><p>
Maybe this is the missing part in Open Source: we have many brilliant
programmers, but next to nobody with a good idea how to design intuitive
user interfaces.
</p><p>
That might be related to the fact that brilliant software engineers, as they
can be found in Open Source, are not exactly known for their social skills,
a human trait that seems to be a very important prerequisite for designing
intuitive user interfaces.
</p><p>
Well, I have <a href=http://git.or.cz/gitwiki/SoC2009Ideas#head-6188833471f79f277e162ef9fbe1592aa10b5f6c>
added</a> the proposal to Git's Summer of Code idea page on the Git Wiki; We will
see what comes out of it.]]></description>
</item>
<item>
<title>The UGFWIINI contest</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232626236</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232626236</guid>
<pubDate>Thu, 22 Jan 2009 13:10:36 +0100</pubDate>
<description><![CDATA[The UGFWIINI contest
</p><p>
Just in case somebody finds this blog, here is a challenge.  Inspired by my
own little hack (this blog), I announce the "Using Git For What It Is Not
Intended" contest.
</p><p>
And it is especially cool, since the acronym sounds cool!  You might miss
this fact if you do no know that I pronounce the "F" like an "A" so that
it sounds cool.
</p><p>
This will be a running contest; whenever I have 10 valid applications, I
will announce a winner on the Git mailing list.
</p><p>
So, what accounts for a valid application?
</p><p>
<ul>
<li> You must use a Git program (the term is used loosely here, GitWeb is
     considered a Git program, for example).
<li> The program must be intended for something completely different than
     what you are using it for.  E.g. GitWeb -- which was intended to let
     you browse through the history using your web browser -- is used
     to serve a blog to the wide world.
<li> You must be able to prove that you actually used the Git program to
     the purpose you claim, preferably in a live demonstration like this
     one.
<li> Nobody and nothing must be harmed in the process (except your
     laughing muscle, that's okay).
</ul>
</p><p>
So, how does such an abuse look like?
</p><p>
<ul>
<li> ... like this blog.
<li> Managing your mail (in maildir format) in a Git repository.
<li> Finding duplicate files by
<table
                                border=1 bgcolor=white>
                        <tr><td bgcolor=lightblue colspan=3>
                                &nbsp;
                        </td></tr>
                        <tr><td>
                                <table cellspacing=5 border=0
                                         style="color:black;">
                                <tr><td>
                                        <pre>
$ git init
$ git add .
$ git ls-files --stage | sort -k2 | uniq -d -s7 -w40
                </pre>
                                </td></tr>
                                </table>
                        </td></tr>
                        </table>
<li> Abusing the Git alias mechanism to call scripts defined directly in
     the config.
</ul>
</p><p>
I am really looking forward to all of your submissions... *chuckles*
</p><p>]]></description>
</item>
<item>
<title>Top-posting</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232611542</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232611542</guid>
<pubDate>Thu, 22 Jan 2009 09:05:42 +0100</pubDate>
<description><![CDATA[Top-posting
</p><p>
Okay, last post for a while.  But this is something that is nagging me
tremendously.  I should probably just let go, but in my deepest inner self,
really close to my heart, I refuse to believe that any human beings could
be incapable of certain degrees of reason.
</p><p>
Take the example of top-posting.  Everybody who read a top-posted email
knows that you have to scroll down, possibly weeding through tons of
pages to find out what the heck the author of the last reply was replying
to.
</p><p>
Never mind that it would take the author of the reply just a couple of
seconds to remove all the irrelevant stuff -- as she already knows what
is the relevant part, saving minutes, in case of mailing lists hours,
easily, to the readers who otherwise would have to discern what is
irrelevant and what is relevant first.
</p><p>
It is a horrible time waste.  But of course not for the top-poster.
</p><p>
The problem is that I frequently run into such people, and when I write
them a polite mail, explaining to them that it is impolite to top-post,
and why, the answers I get sometimes make me check if the sky is still up
and the earth down.  Yesterday was an example of such a dubitable
pleasure.
</p><p>
Most funny are the ridiculous attempts by those persons at explaining why
top-posting is <i>so</i> much superior to anything else.
</p><p>
Which is good, because if they were not that funny, they would be pretty sad.]]></description>
</item>
<item>
<title>Sverre's hat</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232607201</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1232607201</guid>
<pubDate>Thu, 22 Jan 2009 07:53:21 +0100</pubDate>
<description><![CDATA[Sverre's hat
</p><p>
The fun part about a blog is that you can talk about less technical stuff.
For example, Sverre's hat.
</p><p>
Let me start a bit earlier, so that you get the context.
</p><p>
Last year, at the <a href=http://git.or.cz/gitwiki/GitTogether>GitTogether</a>,
we had an <a href=http://en.wikipedia.org/wiki/Unconference>unconference style
conference</a>, which basically meant that it was our job to decide what
we want to talk about.
</p><p>
It turned out to be pretty hard, because there was so much we wanted to
discuss, and because we wanted to get to know each other, and we wanted to
do some hacking.
</p><p>
So to help us decide what subjects, and in which order we wanted to have
scheduled, Shawn opened a series on <a href=http://moderator.appspot.com/>
Google Moderator</a>, a nifty, yet simple application which allows a group
to agree quickly on an agenda.
</p><p>
It worked quite well; However, that little saboteur displayed his sense of
humor so overtly that some entertaining Gitter put the question "Should Sverre
wear a hat?" on the agenda.
</p><p>
Sure enough, the subject got voted up, and eventually, we got Sverre a hat:
</p><p>
<center><img src=2786BLOBPLAIN;hb=30319f7436828cd15db8a531a0057351d8e361c0;f=sverre-hat.jpg sverre-hat.jpg></center>
</p><p>
By the way, another thing I like about this blog engine is that there are no
comments...  Nothing is more annoying than leaving a comment on a blog,
forgetting about it for a few months, and then finding somebody answered
ages ago.
</p><p>
Update: Sverre says it was dsymonds idea.]]></description>
</item>
</channel>
</rss>