Housekeeping on Wednesday, 28th of January, Anno Domini MMIX, at the hour of the...

[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>Wed, 28 Jan 2009 01:18:39 +0100</lastBuildDate>
<language>en-us</language>
<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 can never be dropped (as that would mean
that the patch id of that commit is identical to a patch id of a commit in
the upstream branch; but merge commits do not have a single patch, let alone
a patch id).  So we can be certain that a dropped commit always has at most
one parent.
</p><p>
So what about a root commit?  If that was dropped, we will just substitute
it with the commit onto which we rebase.
</p><p>
The thing that upset me a bit when I found out about it, is what t3410 is
all about.  It speaks about dropping local merges together with their
<u>whole</u> branches when an upstream has the same "merge resolution".
</p><p>
To my surprise, Stephen had no objections to remove that stuff, so I think
I'll be able to submit something usable tomorrow.
</p><p>
Or maybe I will start to use it first...
</p><p>
Another thought that occurred to me is that I could include the output of
<i>git log --graph</i>.  This cannot be done in the rebase script directly,
as there are "goto" and "merge" statements disrupting the graph, and
besides, it would look ugly if you reordered commits without adjusting the
graph, so I may include the graph (for <i>-p</i> only) in the comment section.]]></description>
</item>
<item>
<title>Another midnight riddle?</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233099894</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233099894</guid>
<pubDate>Wed, 28 Jan 2009 00:44:54 +0100</pubDate>
<description><![CDATA[Another midnight riddle?
</p><p>
Okay, here's another riddle: what is the next line?
</p><p>
<pre>
       1
      1 1
      2 1
    1 1 1 2
    3 1 1 2
  2 1 1 2 1 3
...
</pre>
</p><p>
And when does the line get wider than 10 digits?]]></description>
</item>
<item>
<title>Fun with calculus after midnight</title>
<link>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233022809</link>
<guid>http://repo.or.cz/w/git/dscho.git?a=blob_plain;hb=blog;f=index.html#1233022809</guid>
<pubDate>Tue, 27 Jan 2009 03:20:09 +0100</pubDate>
<description><![CDATA[Fun with calculus after midnight
</p><p>
Problem: what is the shortest way of defining a variable consisting of <i>N</i>
spaces?  I.e. for <i>N=80</i> the result will look something like
</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>
s='    '
s="$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s$s"
</pre>
                                </td></tr>
                                </table>
                        </td></tr>
                        </table>
</p><p>
Let's see.  Let the minimal number of characters needed be <i>A(N)</i>.  For
simplicity, let's say that we only use one variable.  Then, certainly, <i>A(N)</i>
cannot be larger than <i>5+N</i>, as we could define a variable using 1 character
for the name, 1 for the equal sign, 2 for the quotes, and one for the semicolon
or newline character (whichever).
</p><p>
Now, let's assume <i>N</i> is a product <i>K*L</i>.  Then certainly, <i>A(N)</i> cannot
be larger than <i>A(K)+5+2*L</i>, as we could first define a variable that has
exactly <i>K</i> spaces and then use that to define the end result (in the example
above, <i>K=5</i> and <i>L=20</i>).
</p><p>
So, for which <i>N=K*L</i> is it better to use two definitions instead of one?
</p><p>
Simple calculus says that <i>5+K*L>5+K+5+2*L</i> must hold true, or (after some
scribbling): <i>L>1+7/(K-2)</i>. Which means that it makes no sense to define
a variable with 1 or 2 spaces first, which is kinda obvious (writing '$s'
alone would use two characters, so we could write the spaces right away).
</p><p>
But what for the other values?  For <i>K=3</i>, <i>L</i> must be at least 9 to make
sense (in other words, <i>N</i> must be at least 27).  For <i>K=4</i>, <i>L</i> needs
to be greater or equal to 5 (<i>N>=20</i>), the next pairs are <i>(5,4)</i>,
<i>(6,3)</i>, <i>(7,3)</i>, <i>(8,3)</i>, <i>(9,3)</i> and starting with <i>K=10</i>, any
<i>L>1</i> makes sense.
</p><p>
The second definition can also contain spaces at the end, however, so for any
<i>N=K*L+M</i>, <i>A(N)</i> cannot be larger than <i>A(K)+5+2*L+M</i>.
</p><p>
Not surprisingly, this leads to exactly the same <i>L>1+7/(K-2)</i> (as we can
append the <i>M</i> spaces in the last definition, no matter if we use 1 or
2 definitions).
</p><p>
However, that means that as soon as <i>N>=18</i>, we should use two definitions,
prior to that, it makes no sense.
</p><p>
So for <i>N<18</i>, <i>A(N)=5+N</i>.
</p><p>
But what <i>K</i> should one choose, i.e. how many spaces in the first definition?
In other words, what is <i>A(N)</i> given that we use two definitions?
</p><p>
That will have to wait for another midnight.  Just a teaser: <i>A(80)=36</i>.  Oh,
and with 80 characters, you can define a string of 9900 spaces...]]></description>
</item>
<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>
                                <pre>                                                                                </pre>
                        </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>
                                <pre>                                                                                </pre>
                        </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_words_show()</i>, we basically get the minus lines as
<i>diff_words->minus</i> and the plus lines as <i>diff_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_out_diff_words_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_words</i>
struct,
<li>having a special handling for that mode in
<i>fn_out_diff_words_aux()</i> that appends the offsets and
returns,
<li>adding a function <i>show_lines_with_colored_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_words_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_words_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="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-ambigram.svg" width=317 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=dscho.git?a=blob_plain;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="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-gitk-logo.svg" width=325 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=dscho.git?a=blob_plain;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="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=git-visual-test.svg" width=325 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=dscho.git?a=blob_plain;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="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=gitlogo.svg" width=165 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=dscho.git?a=blob_plain;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="dscho.git?a=blob_plain;hb=aaa9edafbe6ca5349ad7b36848fb294e5f4fc529;f=original-git-logo.svg" width=165 />
                        </td>
                </tr>
                <tr>
                        <td align=center>
                                <a href=dscho.git?a=blob_plain;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>
</channel>
</rss>